Re: adding XML support (without new OS image)
From: John Spaith [MS] (jspaith_at_ONLINE.microsoft.com)
Date: 09/29/04
- Next message: Yannick Chamming's [eMVP]: "Re: Is there a BSP for PXA25x on WinCE 5.0 ?"
- Previous message: Sujith: "Re: This is not a .BIN file FF FF FF FF FF FF FF"
- In reply to: jj3000: "Re: adding XML support (without new OS image)"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 28 Sep 2004 21:15:02 -0700
None of this is sounding good I'm afraid. The coredll.dll being of
different sizes is a clue. Basically the OS is componentized not only at
the DLL level (i.e. you have shlwapi.dll on the image or you don't) but also
in the case of coredll.dll at a function by function level. So the larger,
newer coredll has more functions in it and is bigger. The reason it is is
because the build system, when you selected MSXML, was smart enough to add
all the other stuff in coredll that msxml/wininet/urlmon depended on.
Replacing coredll on a shipping system is a much harder problem than adding
msxml3. I don't even know if it's possible - somenone on the group may
know. I suspect the answer is no. If you don't get a response on this
thread, I'd create a new one with a new subject.
There's one last hope for msxml3 with your existing image. MSXML3, like
coredll, is componentized across the DLL level. It's docced in MSDN pretty
extensively how you can mix + match components in an msxml build - i.e DOM,
SAX, XSLT, etc... So if all you needed was say the MiniSAX parser (very
small dependency requirment on OS), but the msxml3 you're building contains
say XPATH and XMLHTTP (both require tons of components), then you may
consider rebuilding your msxml3 such that it only contains miniSAX. Depends
on what featuers you need. Note if you only build miniSax or the DOM by
itself and maybe a few of the more lightweight components, componentization
may (I'm not sure) work such that you don't need urlmon/shlwapi/wininet
DLL's. MSXML can in theory be built with httplite.dll, which is a tiny
winenet replacement available mostly for OS stuff that wants to use wininet
functionality but not take a huge ROM hit. So... the upshot of this is that
coredll required by miniSax may be satisfied by coreDll on the existing
device itself.
You can run 'link /dump /imports msxml3.dll' to see what msxml3 is bringing
in.
If none of this works, you're on your own I'm afraid. You're already way
out of officially supported scenarios (technical I'm sure, legal you need to
check even if you can fix technical problems). Beyond that you're getting
to be at the end of my knowledge, though I would be curious if you can get
this going and I'm pulling for you.
-- John Spaith Software Design Engineer, Windows CE Microsoft Corporation Check out the new CE Networking Team Blog at http://blogs.msdn.com/cenet/. This posting is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use. © 2003 Microsoft Corporation. All rights reserved. "jj3000" <jeremy_ho@my-deja.com> wrote in message news:3ed9e158.0409281612.eb4734e@posting.google.com... > 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 >>
- Next message: Yannick Chamming's [eMVP]: "Re: Is there a BSP for PXA25x on WinCE 5.0 ?"
- Previous message: Sujith: "Re: This is not a .BIN file FF FF FF FF FF FF FF"
- In reply to: jj3000: "Re: adding XML support (without new OS image)"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
|
