Re: adding XML support (without new OS image)

From: jj3000 (jeremy_ho_at_my-deja.com)
Date: 09/29/04 

Date: 28 Sep 2004 17:12:37 -0700

Thanks John for the tips so far,

For our registry "hive" I am able to run the newer registry settings
completely intact from the newer XML image but with the older non-XML
nk.bin. So all the registries are there.

So then I wrote a program LoadLibrary(_T("\\windows\\msxml3.dll")) and
check for return code and error.

Just by the msxml3.dll in the windows directory, it would fail with
error 126. (file not found)

Until I also copy these DLLs to the windows directory
 shlwapi.dll
 urlmon.dll
 wininet.dll

Then the error would change to 193 (Not a valid win32 application)

I am kind of stuck at this point. As a desperate test I also copied
every DLL that was in the XML build to the windows directory (only the
new ones because the existing named DLLs are locked), and it doesn't
change the error code any further.

What bugs me is that some of the things like coredll.dll is different
sized between the 2 OS images.

Any idea how to proceed? I understand this is all theory testing and
I accept the possiblity it might not work. But I want to understand
what is going on.

"John Spaith [MS]" <jspaith@ONLINE.microsoft.com> wrote in message news:<OWD1klMpEHA.2484@TK2MSFTNGP09.phx.gbl>...
> There's 2 fronts you need to investigate this on. The first is the
> technical, which I can do my best to help with. The other is legal, as far
> as whether you can redistribute components on existing images or not. I
> personally don't have any problems if you do this. Remember however that
> John==Engineer, John!=Microsoft Legal Department :). I'd talk with your
> technical accounts manager about this and they can get you the definitive
> answer.
>
> In theory an image built without MSXML3 can have it added after the fact.
> As you already realize, the underlying OS has to have all the required
> components for MSXML in order for this to work. First off you'll need all
> the registry settings for msxml3.dll. These can be found in ie.reg of an
> image that you've created to get msxml3.dll bits in the first place.
>
> After that, I'd focus on making sure that MSXML3.dll not having the required
> OS support is your problem. Write a small app that just does a
> LoadLibrary("msxml3.dll") and see if it succeeds or if it fails. If it
> suceeds, then it would look like msxml3 dll being not setup right isn't the
> problem. Maybe the registry is incorrect or there's something wrong in your
> test app? If this fails, first see if the error code returned makes it
> obvious what the problem is. If not, if possible create a debug version of
> the OS image that you're targeting and a debug msxml3.dll. Then in Platform
> Builder turn on nk.exe's debug zone for the loader. This should tell you
> exactly which function or functions the linker is missing when trying to do
> the load if this is the problem.
>
> Let me know how this works out and if there's anything else I can help with
> once you try the steps above.
>
> --
> John Spaith
> Software Design Engineer, Windows CE
> Microsoft Corporation
>

Relevant Pages

  • "APPINIT_DLLS=" error and ".wll" error
    ... Ok first off I have no knowledge of registry problems or how to fix them. ... All the DLLs that are specified in this value are loaded by each Microsoft ... Note This feature may not be available in future versions of the Windows ... Microsoft Windows 2000 Standard Edition ...
    (microsoft.public.windowsupdate)
  • Re: ftp from Access: problems
    ... > You obviously have no idea what is meant by hardcoding, how OLE dlls ... > registered an entry in the registry points to the correct file. ... You say it's unprofessional to hard-code ...
    (comp.databases.ms-access)
  • Help!: Problems with Restricted access accounts
    ... series of business object DLLs that need to be registered on each local ... Our clients have their users set up as Restricted user accounts. ... the user tries again as a restricted access user account, ... seems that the user is unable to "see" the DLL entries in the registry. ...
    (microsoft.public.windowsxp.security_admin)
  • Re: How to work around UAC?
    ... In these situations, and with UAC active, our DLLs no longer ... have access to our software's registry keys. ... your DLLs DO have access to HKLM - but read only. ...
    (microsoft.public.platformsdk.security)
  • Logon Problem
    ... EXPLORER.EXE (and a few DLLs) some time ago. ... be a prankster (not a virus) is having fun at your expense. ... >other things in the registry. ... >the run and the run once keys to ensure that no seemingly ...
    (microsoft.public.windowsxp.general)