Kyle Huey (Exited; not receiving bugmail, old account, do not use)

Comment 3

•

13 years ago

So the problem is the actual generated code, not the CRT?

Jim Mathies [:jimm]

Reporter

•

13 years ago

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #5) > What non-XP system-library APIs do our libraries pull in, and why? The crt src pulls these new apis in. If you have vc11 installed you can do searches across the crt source (VC\crt\src) for a specific api to find where they are used.

Robert O'Callahan (:roc) (email my personal email if necessary)

•

13 years ago

Writing a tool to redirect those symbols is rather easy. But the functions that I see there are not trivial to implement, and we can't quite get away with dummy no-op impls. I've looked into this issue extensively when I was trying to find a way to run the VC10 generated binaries on Win2K. All of the available solutions suck, some more than others. I don't think we can get away with not using two compilers. Why is that difficult for releng?

Robert O'Callahan (:roc) (email my personal email if necessary)

Comment 14

•

13 years ago

http://tedwvc.wordpress.com/2012/03/11/how-to-get-visual-c-2012-vc-11-beta-statically-linked-crt-and-mfc-applications-to-run-on-windows-xp/ is all about reimplementing those functions to work on WinXP. That blogger supposedly has code for them, but I haven't looked at it myself.

Jim Mathies [:jimm]

Reporter

Comment 15

•

13 years ago

I'm curious about where the dlls come from on XP. When you checkout the src from mc, the runtime dlls don't come down with the src. I'm betting this is due to licensing. For people building on Vista and up with VC11 the runtime will be present and won't require any changes. But building on XP will require modifications. How concerned are we about people building on XP? Maybe we just tell them they have to round up these dlls and run the modification tool manually? Note the dlls will also need to be reversioned so that they can load. (All of our dlls will also need to be reversioned but we can do that during the build process.)

(no longer active)

Comment 16

•

13 years ago

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) (offline April 15-18) from comment #14) > http://tedwvc.wordpress.com/2012/03/11/how-to-get-visual-c-2012-vc-11-beta- > statically-linked-crt-and-mfc-applications-to-run-on-windows-xp/ is all > about reimplementing those functions to work on WinXP. That blogger > supposedly has code for them, but I haven't looked at it myself. Yeah, I took a look at that. Some of those implementations are heavily broken depending on what the crt does (for example, if the crt uses fibers, the implementation of FlsAlloc and friends can seriously break things.

(no longer active)

Comment 17

•

13 years ago

(In reply to Jim Mathies [:jimm] from comment #15) > I'm curious about where the dlls come from on XP. When you checkout the src > from mc, the runtime dlls don't come down with the src. I'm betting this is > due to licensing. For people building on Vista and up with VC11 the runtime > will be present and won't require any changes. But building on XP will > require modifications. > > How concerned are we about people building on XP? Maybe we just tell them > they have to round up these dlls and run the modification tool manually? > Note the dlls will also need to be reversioned so that they can load. (All > of our dlls will also need to be reversioned but we can do that during the > build process.) I'm confused now. Is this a problem of building *on* Windows XP or *for* Windows XP? I was assuming the former. We can always change our build requirements to require Vista and 7, I don't think building on XP should hold us back at all.

Jim Mathies [:jimm]

Reporter

Comment 18

•

13 years ago

(In reply to Ehsan Akhgari [:ehsan] from comment #17) > (In reply to Jim Mathies [:jimm] from comment #15) > > I'm curious about where the dlls come from on XP. When you checkout the src > > from mc, the runtime dlls don't come down with the src. I'm betting this is > > due to licensing. For people building on Vista and up with VC11 the runtime > > will be present and won't require any changes. But building on XP will > > require modifications. > > > > How concerned are we about people building on XP? Maybe we just tell them > > they have to round up these dlls and run the modification tool manually? > > Note the dlls will also need to be reversioned so that they can load. (All > > of our dlls will also need to be reversioned but we can do that during the > > build process.) > > I'm confused now. Is this a problem of building *on* Windows XP or *for* > Windows XP? I was assuming the former. We can always change our build > requirements to require Vista and 7, I don't think building on XP should > hold us back at all. I was asking about specific issues with building on XP, and you answered my question. We can just define our build requirements to be Vista+. Might anger a few folks, but such is life. Getting VC11 builds running on XP is the main focus of this bug.

(not currently active) Ted Mielczarek

Comment 19

•

13 years ago

It's certainly fine to require Vista or newer for building for Win8 with VC11. The only tricky bit might be the build slaves, which IIRC are all still Win2k3.

(no longer active)

•

13 years ago

Maybe there is some confusion - we are going to integrate metro code bits into the Firefox build/installer on mc. So basically when you build or download firefox you'll also be building/downloading the metro bits, even if you are not on win8. To do this, all firefox builds will have to happen on VC11 with the win8 sdk. Here's the details of the plan: https://wiki.mozilla.org/Firefox/Windows_8_Integration#A_tentative_proposal

(no longer active)

Comment 24

•

13 years ago

OK, I chatted about this with Jim a bit, and he asked me to summarize my thoughts here. * Linking statically to the crt is not a good option, for code size/memory usage reasons. And even if we decide that we don't care about any of that, we have no evidence to suggest that we can effectively simulate the missing crt import entries with our hacky implementations on WinXP. * Fixing our binaries up with dynamic linking at runtime is impossible -- I've already experimented with this. There's just too many details in the Windows loader over which we have zero control. * Fixing our binaries at build time with a tool _could_ be an option, but we need to figure out whether we're allowed to binary patch Microsoft crt DLLs legally. And we still have to answer the same question as the first point above. * We could potentially use two compilers in the build process, and avoid building _anything_ which needs to be loaded on XP with VC11. I don't know much about the winrt code, so I don't know how practical the surgery is. If that is not very hard, using two compilers might be the way to go. * Failing that, the _only_ remaining option that I can think of is having two completely separate builds, one using VC10 for Win7 and lower, and one using VC11 for Win8 only. We obviously don't want to bundle both into the same installer because of download size, so we're going to need a stub installer (unless the product team says that doubling our Windows download size is OK.) FWIW, I think that moving XP users to the ESR branch is the wrong thing to do. We just have too many users on that platform to deprive them of the latest and greatest features on the web.

neil@parkwaycc.co.uk

Comment 25

•

•

•

13 years ago

Oops, sorry, I spoke too soon. It's still pulling in the newer 110 dlls from windows/system32. I need to try again with the right import libraries.

(no longer active)

•

13 years ago

Forgot one - 7) statically link to the crt and bake missing entry points into our code. Actually not that bad of a solution - we have about 12 dlls and one exe. If we remove the crt dlls from the install and add back multiple copies of the crt code we use, the size differences might not be too bad once compressed.

(no longer active)

Comment 45

•

13 years ago

(In reply to Jim Mathies [:jimm] from comment #43) > Notes thus far from looking at various possible solutions. Of the options > that might work, none are really very likable. > > 1) patching the crt dlls on install / first run > > - entry point in which to do the patch work (zip install problem) I think we might wanna do this at startup for zip installations, but it requires us to make sure that the executable which runs the first time that Firefox is launched does not link against those missing functions. Also, this will most likely break installations on network drivers which are used by both Win7 and WinXP users, for example... > - patch would rename kernel32.dll crt dll import table > - we provide a moz kernel32 wrapper which implicitly links to kernel32.dll > and is built with vs2010. > - wrapper provides missing entry points and calls through to kernel32 > - moz wrapper would need all the kernel32 exports defined, pita but possible. > - our dlls also import one missing entry point, can we bake this into our > code to fix? I don't like this at all. How about the patch tool reading the import table of kernel32, remove those, and point them to our own shim DLL, and rewrite the PE image with the new import table? This will make sure that we won't run into problems caused by us redirecting a symbol by mistake, etc. > 2) delay load the crt and patch up crt entry points in a delay load hook > > - can't delay load crt or kernel32.dll, both implicitly linked I have experimented with this idea, and unfortunately I could not get it to work, because of the above reason. > 3) working directory replacement shim for kernel32.dll > > - would need all kernel32 entry points > - how would the wrapper get access to kernel32.dll? circular reference > problem? > - simpler than option #1 AFAIK, Windows will never attempt to load a DLL named kernel32 from the app directory. > 4) Link to the older crt lib stubs/dlls with new tools > > - can't, linker checks lib stub and target compiler versions, fails if they > don't match. > > 5) split the metro widget code out into a separate library > > - bad: two sets of build tools to build firefox > - no new c++ language features in platform > - no assurances it will actually work > > 6) create vs2010 builds for xp users, vs11 builds for newer os > > - releng pain > - user pain / confusion > - no new c++ language features in platform (In reply to Jim Mathies [:jimm] from comment #44) > Forgot one - > > 7) statically link to the crt and bake missing entry points into our code. > > Actually not that bad of a solution - we have about 12 dlls and one exe. If > we remove the crt dlls from the install and add back multiple copies of the > crt code we use, the size differences might not be too bad once compressed. This will at least cause us take a startup hit, since we'll need to read multiple copies of the same code from disk. It won't be 12x the amount of current code, since the linker would strip out the unused stuff, but the CRT is like a spaghetti plate, a lot of its code is entangled with every other piece. Someone needs to do measurements here, but I would not be surprised if this adds a few megs of more I/O to do at startup. Although if you convince bsmedberg that this is the way to go, I won't object too much. ;-)

Jim Mathies [:jimm]

Reporter

Comment 46

•

13 years ago

(In reply to Ehsan Akhgari [:ehsan] from comment #45) > > - patch would rename kernel32.dll crt dll import table > > - we provide a moz kernel32 wrapper which implicitly links to kernel32.dll > > and is built with vs2010. > > - wrapper provides missing entry points and calls through to kernel32 > > - moz wrapper would need all the kernel32 exports defined, pita but possible. > > - our dlls also import one missing entry point, can we bake this into our > > code to fix? > > I don't like this at all. How about the patch tool reading the import table > of kernel32, remove those, and point them to our own shim DLL, and rewrite > the PE image with the new import table? This will make sure that we won't > run into problems caused by us redirecting a symbol by mistake, etc. If you think we can do all that rewriting of the crt dlls I'm fine with that. I was looking for the simplest approach. Since the crt dlls only have one dll listed in their import table, I'm assuming you feel we can add additional dlls to that list and rewrite the whole dll without messing up all the addressing? Personally I've never attempted anything like this before so I'm curious if it's not as big a deal as it feels. > This will at least cause us take a startup hit, since we'll need to read > multiple copies of the same code from disk. It won't be 12x the amount of > current code, since the linker would strip out the unused stuff, but the CRT > is like a spaghetti plate, a lot of its code is entangled with every other > piece. Someone needs to do measurements here, but I would not be surprised > if this adds a few megs of more I/O to do at startup. Although if you > convince bsmedberg that this is the way to go, I won't object too much. ;-) I'm going to experiment to get some measurements. At the end of the day this is looking like the simplest, most error free solution assuming no major perf regressions. Size of the install really shouldn't be a show stopper, assuming it's not megs of data.

(no longer active)

Comment 47

•

13 years ago

(In reply to Jim Mathies [:jimm] from comment #46) > (In reply to Ehsan Akhgari [:ehsan] from comment #45) > > > - patch would rename kernel32.dll crt dll import table > > > - we provide a moz kernel32 wrapper which implicitly links to kernel32.dll > > > and is built with vs2010. > > > - wrapper provides missing entry points and calls through to kernel32 > > > - moz wrapper would need all the kernel32 exports defined, pita but possible. > > > - our dlls also import one missing entry point, can we bake this into our > > > code to fix? > > > > I don't like this at all. How about the patch tool reading the import table > > of kernel32, remove those, and point them to our own shim DLL, and rewrite > > the PE image with the new import table? This will make sure that we won't > > run into problems caused by us redirecting a symbol by mistake, etc. > > If you think we can do all that rewriting of the crt dlls I'm fine with > that. I was looking for the simplest approach. Since the crt dlls only have > one dll listed in their import table, I'm assuming you feel we can add > additional dlls to that list and rewrite the whole dll without messing up > all the addressing? > > Personally I've never attempted anything like this before so I'm curious if > it's not as big a deal as it feels. This will not be easy (we'll need to write a micro-linker!) but I believe it would be possible. Relying on the assumption that we'll properly take care of all kernel32 import entries is way scarier IMO. > > This will at least cause us take a startup hit, since we'll need to read > > multiple copies of the same code from disk. It won't be 12x the amount of > > current code, since the linker would strip out the unused stuff, but the CRT > > is like a spaghetti plate, a lot of its code is entangled with every other > > piece. Someone needs to do measurements here, but I would not be surprised > > if this adds a few megs of more I/O to do at startup. Although if you > > convince bsmedberg that this is the way to go, I won't object too much. ;-) > > I'm going to experiment to get some measurements. At the end of the day this > is looking like the simplest, most error free solution assuming no major > perf regressions. Size of the install really shouldn't be a show stopper, > assuming it's not megs of data. OK, let's see what happens here. Also, please make sure to do PGO builds for measurements. Thanks!

Jim Mathies [:jimm]

Reporter

Comment 48

Comment 54

•

13 years ago

(In reply to Ehsan Akhgari [:ehsan] from comment #52) > The shim DLL which IAT-fixer redirects the missing functions can just look > at kernel32.dll at runtime, and call the existing implementation if there is > one. I didn't think of that. That makes complete sense and is definitely the right way to go, if we can do it legally.

Gervase Markham [:gerv]

•

13 years ago

(In reply to Gervase Markham [:gerv] from comment #55) > (But I thought we used to distribute a modified CRT with jemalloc in it; am > I confused about that? If so, there will be legal analysis of how that's > possible knocking around somewhere.) We used to compile a patched CRT from source. Microsoft provides the CRT sources with VC++ for this express purpose. Unfortunately as of VC2010 they stopped providing the build scripts to compile the sources, so that option is much more difficult.

Mike Hommey [:glandium]

Comment 59

•

13 years ago

(In reply to Ted Mielczarek [:ted] from comment #58) > (In reply to Gervase Markham [:gerv] from comment #55) > > (But I thought we used to distribute a modified CRT with jemalloc in it; am > > I confused about that? If so, there will be legal analysis of how that's > > possible knocking around somewhere.) > > We used to compile a patched CRT from source. Microsoft provides the CRT > sources with VC++ for this express purpose. Unfortunately as of VC2010 they > stopped providing the build scripts to compile the sources, so that option > is much more difficult. OTOH, we have the machinery to kind of patch the CRT from its binary, which we do for free().

Benjamin Smedberg

Comment 60

•

13 years ago

Assuming Microsoft has actually supplied all the sources for the CRT, I really don't think it would be that hard to come up with build scripts for it, at least in the particular configuration that we care about (multithreaded DLL). The tangled mess that was the original build scripts was mainly dealing with a bunch of different configurations.

(not currently active) Ted Mielczarek

Comment 61

•

13 years ago

My MSVC2010 install dir has: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt\src Someone could check the corresponding VC2011 sources.

Jim Mathies [:jimm]

Reporter

Comment 62

•

13 years ago

According to this social post, the current source is missing key binaries - http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/e6f222d7-8e20-4d4a-8a6f-b72ade3661ac Ehsan might have something to say about this as he looked looked into trying to do this with 2010. I also took a stab at it using the 2008 build scripts. Unfortunately things have changed quite a bit so those are not of much help.

(no longer active)

Comment 63

•

13 years ago

Yeah, IIRC it was not only the build script missing, but some object files which used to come with the CRT without the corresponding source are missing as well, so we can't really link a binary even if we simulate the build script.

Robert O'Callahan (:roc) (email my personal email if necessary)

•

13 years ago

Just and FYI, we don't have a definitive answer yet on the licensing so we've sent this over to Harvey for analysis. Will post back when I hear back from him.

jfwfreo

Comment 67

•

13 years ago

I cant speak as to the licensing but I have done an analysis of the VS11 pro beta from Microsoft (available at http://www.microsoft.com/visualstudio/11/en-us/downloads ) and I can say that whilst it contains more of the CRT source code than my VS10 pro install, it does not appear to contain everything required to recompile msvcr110.dll. Not only is there not enough information on how to compile the CRT (compiler flags, which files to link into the different dlls etc) but an analysis of msvcrt.lib and msvcr110.dll shows that there is code linked into those files that is NOT included in the CRT source. (atlssup.obj being one example of a file that is included in the the CRT binaries but not in the CRT source)

(no longer active)

Comment 68

•

12 years ago

Just as a status update, I've been buried with the work on background updates, and have had no time to work on this so far.

Jim Mathies [:jimm]

Reporter

Comment 69

•

12 years ago

The opinion of legal came back last week - generally, we can't modify these dlls either during the build or on the client side. This doesn't leave us a whole lot of options. If we stick with a single compiler we'll be using the VC 2010 version for as long as we support XP and our win8 work will be negatively impacted. Rob mentioned the possible use of a stub install that brings down the right resources depending on the os. This would involve dual builds on the rel eng side. Not sure how it would affect the updater. Some investigation is needed. If anyone has any additional ideas, please post.

jfwfreo

Comment 70

•

12 years ago

I haven't played with the Mozilla codebase in a while so I dont know how fesable this is but here is my idea: 1.Build a full set of release builds (FF, TB, SM etc) with VS11 in the form that would run on XP were it not for these few kernel functions. 2.Produce a list of all the imports these dlls import from the CRT DLLs 3.Then with this list, there are 3 options, option 1 is to replace that function with a functionally equivalent clone added to one of the core moz dlls (either existing-and-suitably-licensed or new-for-Mozilla), option 2 is to statically link a single copy of the function from the static CRT libraries into the aforementioned core dlls and have all the other bits of the codebase link to this one copy 4.For each function that is dealt with under point 3, it may have further dependencies on other functions that will also need to be dealt with. There ARE ways to have the linker use <function X> from <lib Y> instead of from the CRT library, I have used them before. There is also this: http://www.benshoof.org/blog/minicrt/ where its clear other people have thought about ways to reduce/eliminate dependencies on the Microsoft CRT for the purpose of smaller code size (even Google has done something with it for one of their installers) although it seems to be stuck around VS2008 and doesn't cover VS10 or VS11. But it might provide some insight that could be used in this effort.

jfwfreo

Comment 71

•

12 years ago

Obviously after that is done, you can then add the appropriate clones/stubs for the remaining missing-on-XP kernel functions which get linked into a shared dll and exposed to the rest of the dlls. And you would still need a separate Metro dll only loaded on Windows 8 (or a separate "Windows 8 with Metro" build for Windows 8 users)

Brian R. Bondy [:bbondy]

Comment 72

•

12 years ago

> Rob mentioned the possible use of a stub install that brings down the right > resources depending on the os. This would involve dual builds on the rel > eng side. Not sure how it would affect the updater. Some investigation is needed. I think it would make the most sense to just treat Windows 8 and beyond as a separate platform with its own installer and update MAR completely. This would also allow us to do anything win8 and beyond with a simple #ifdef XP_WIN8 check instead of loading it in dynamically. If we did the opposite and only left XP as its own build, I think we'll run into this same problem when MS stops supporting Vista. This wouldn't require a stub installer but would be nicest with one. Without the stub we would just have a bit of web work to do to redirect to the correct download depending on the OS. For updates if we detected that the user is using a build less than win8 but is on a higher or equal version of win8 computer then we would upgrade them to the other platform with a full MAR.

Jim Mathies [:jimm]

Reporter

Comment 73

•

12 years ago

(In reply to jfwfreo from comment #70) > I haven't played with the Mozilla codebase in a while so I dont know how > fesable this is but here is my idea: > 1.Build a full set of release builds (FF, TB, SM etc) with VS11 in the form > that would run on XP were it not for these few kernel functions. > 2.Produce a list of all the imports these dlls import from the CRT DLLs > 3.Then with this list, there are 3 options, option 1 is to replace that > function with a functionally equivalent clone added to one of the core moz > dlls (either existing-and-suitably-licensed or new-for-Mozilla), option 2 is > to statically link a single copy of the function from the static CRT > libraries into the aforementioned core dlls and have all the other bits of > the codebase link to this one copy > 4.For each function that is dealt with under point 3, it may have further > dependencies on other functions that will also need to be dealt with. Interesting idea, basically build our own crt library that statically links to the real crt and also adds the missing system exports so it can load on XP. We would also have to link the missing system exports component into our other statically linked modules, like webaprt and a couple of the glue libs.

(no longer active)

Comment 74

•

12 years ago

(In reply to Jim Mathies [:jimm] from comment #73) > (In reply to jfwfreo from comment #70) > > I haven't played with the Mozilla codebase in a while so I dont know how > > fesable this is but here is my idea: > > 1.Build a full set of release builds (FF, TB, SM etc) with VS11 in the form > > that would run on XP were it not for these few kernel functions. > > 2.Produce a list of all the imports these dlls import from the CRT DLLs > > 3.Then with this list, there are 3 options, option 1 is to replace that > > function with a functionally equivalent clone added to one of the core moz > > dlls (either existing-and-suitably-licensed or new-for-Mozilla), option 2 is > > to statically link a single copy of the function from the static CRT > > libraries into the aforementioned core dlls and have all the other bits of > > the codebase link to this one copy > > 4.For each function that is dealt with under point 3, it may have further > > dependencies on other functions that will also need to be dealt with. > > Interesting idea, basically build our own crt library that statically links > to the real crt and also adds the missing system exports so it can load on > XP. We would also have to link the missing system exports component into our > other statically linked modules, like webaprt and a couple of the glue libs. That would only work in case the static stuff that VC links into binaries do not depend on the missing exports.

jfwfreo

Comment 75

•

12 years ago

You could create a clone of GetTickCount64 and export that from some linked-into-every-other-Mozilla-binary glue library which is then used by every binary in place of the kernel32.dll version of that function (GetTickCount64 is the one non-XP function imported by the static-linked code in msvcrt.lib)

jfwfreo

Comment 76

•

12 years ago

Attached file msvcr110.dll/msvcp110.dll imports used by Firefox — Details

Further to my ideas from before, I have done some tests to identify all the imports from msvcr110.dll and msvcp110.dll that Firefox is currently using. What I did was as follows: 1.Install Microsoft Visual Studio 11 Beta (cl.exe claims its version 17.00.50214.1) 2.Build mozilla-central following these instructions https://developer.mozilla.org/en/Windows_8 using revision 5a4551a75db3 and the following .mozconfig: mk_add_options MOZ_MAKE_FLAGS="-s -j4" ac_add_options --disable-angle 3.Make a dist zip file of the resulting build 4.Unzip the zip file and run an import dumper on each exe and dll to identify anything they imported from msvcr110.dll and msvcp110.dll The results are attached, its a list of all exports from msvcr110.dll and msvcp110.dll that are used by my test vs11 Firefox build. I am also investigating a way to identify the symbols pulled in from the static libraries (msvcrt.lib etc) probably by generating a map file and parsing the results of that. The way I see it, we have 3 choices of how to proceed if we want to go down this road (as opposed to having a separate vs11/metro build or whatever) 1.We continue to link to msvcrt.lib but replace the imports from msvcr110.dll and msvcp110.dll with imports from a Mozilla dll with functions that do an equivalent job (how you come up with those functions would have to be identified) 2.We go further and use my .map file idea above and then replace some parts of the static msvcrt.lib/msvcprt.lib with our new implementations in addition to replacing the msvcr110.dll/msvcp110.dll functions. or 3.We take the approach of the minicrt/libctiny I linked to before. This would involve building a full-static (i.e. linked to libcmt.lib/libcpmt.lib) copy of FF, somehow identifying all the symbols that the FF obj files need from libcmt.lib/libcpmt.lib and then providing an implementation of each one. The implementation could be the implementation in libc*.lib, an existing implementation from elsewhere (that's under a suitable license) or a new impelementation. Some of these implementations could live in a shared Mozilla dll, others would need to be linked into each binary.

Jim Mathies [:jimm]

Reporter

Comment 77

•

12 years ago

(In reply to jfwfreo from comment #76) > Created attachment 632156 [details] > msvcr110.dll/msvcp110.dll imports used by Firefox > > Further to my ideas from before, I have done some tests to identify all the > imports from msvcr110.dll and msvcp110.dll that Firefox is currently using. > What I did was as follows: > 1.Install Microsoft Visual Studio 11 Beta (cl.exe claims its version > 17.00.50214.1) > 2.Build mozilla-central following these instructions > https://developer.mozilla.org/en/Windows_8 using revision 5a4551a75db3 and > the following .mozconfig: > mk_add_options MOZ_MAKE_FLAGS="-s -j4" > ac_add_options --disable-angle > 3.Make a dist zip file of the resulting build > 4.Unzip the zip file and run an import dumper on each exe and dll to > identify anything they imported from msvcr110.dll and msvcp110.dll > > The results are attached, its a list of all exports from msvcr110.dll and > msvcp110.dll that are used by my test vs11 Firefox build. > > I am also investigating a way to identify the symbols pulled in from the > static libraries (msvcrt.lib etc) probably by generating a map file and > parsing the results of that. > > The way I see it, we have 3 choices of how to proceed if we want to go down > this road (as opposed to having a separate vs11/metro build or whatever) > 1.We continue to link to msvcrt.lib but replace the imports from > msvcr110.dll and msvcp110.dll with imports from a Mozilla dll with functions > that do an equivalent job (how you come up with those functions would have > to be identified) If we can get it to work I like option one. Replacing any part of the crt with 3rd party code has overhead in terms of testing and security review work. It would be simpler to use the existing static crt if we can. As far kernel32 exports we have a starting point in this work - http://tedwvc.wordpress.com/2012/03/11/how-to-get-visual-c-2012-vc-11-beta-statically-linked-crt-and-mfc-applications-to-run-on-windows-xp/ There's no license on this code so we may end up having to clean room our own but before we do that we can test the experiment and if we think it'll work contact the author about usage.

jfwfreo

Reporter

Comment 99

•

12 years ago

(In reply to jfwfreo from comment #97) > My next step is going to be to look at my list from earlier and see what we > might have in-tree that could potentially be a suitable replacement (e.g. if > we have anything in NSPR) Wouldn't it be easier to statically link to the Win runtime lib and have this dll act as a pass through for most everything?

jfwfreo

Comment 100

•

•

12 years ago

Depends on: 794983

Yuhong Bao

•

12 years ago

Personally, I found out that you don't even need the older SDK with VS2012, you can use 8.0; meaning with VS2012 with KB2707250 (Update1) installed, you'd only need -SUBSYSTEM:WINDOWS,5.01 in the linker command line to build for XP compatibility, everything else just works. I'm still using the DirectX SDK Jun2010 aside from the built-in SDKs, but that's all. Building with VS2012 seems to link much faster than 2010, and I haven't run into any resource issues with PGO.

Jim Mathies [:jimm]

Reporter

Comment 144

•

12 years ago

Attached patch xp compat build — Details — Splinter Review

(no longer active)

Comment 145

•

12 years ago

(In reply to comment #144) > Created attachment 705834 [details] [diff] [review] > --> https://bugzilla.mozilla.org/attachment.cgi?id=705834&action=edit > xp compat build Nice! Can we take this patch? I don't think that it should negatively impact the VS2010 builds...

Mike Hommey [:glandium]

Comment 146

•

12 years ago

Comment on attachment 705834 [details] [diff] [review] xp compat build Review of attachment 705834 [details] [diff] [review]: ----------------------------------------------------------------- The nspr and nss changes will have to be separated. ::: configure.in @@ +2135,5 @@ > MKSHLIB='$(LD) -NOLOGO -DLL -OUT:$@ -PDB:$(LINK_PDBFILE) $(DSO_LDOPTS)' > MKCSHLIB='$(LD) -NOLOGO -DLL -OUT:$@ -PDB:$(LINK_PDBFILE) $(DSO_LDOPTS)' > MKSHLIB_FORCE_ALL= > MKSHLIB_UNFORCE_ALL= > + DSO_LDOPTS= Do you really mean to remove the flag from link.exe calls? (the config.mk change doesn't quite replace it)

Jim Mathies [:jimm]

Reporter

Comment 147

•

12 years ago

(In reply to Mike Hommey [:glandium] from comment #146) > Comment on attachment 705834 [details] [diff] [review] > xp compat build > > Review of attachment 705834 [details] [diff] [review]: > ----------------------------------------------------------------- > > The nspr and nss changes will have to be separated. > > ::: configure.in > @@ +2135,5 @@ > > MKSHLIB='$(LD) -NOLOGO -DLL -OUT:$@ -PDB:$(LINK_PDBFILE) $(DSO_LDOPTS)' > > MKCSHLIB='$(LD) -NOLOGO -DLL -OUT:$@ -PDB:$(LINK_PDBFILE) $(DSO_LDOPTS)' > > MKSHLIB_FORCE_ALL= > > MKSHLIB_UNFORCE_ALL= > > + DSO_LDOPTS= > > Do you really mean to remove the flag from link.exe calls? (the config.mk > change doesn't quite replace it) I'm sure there are different ways to do it. If you leave the subsystem directive in DSO_LDOPTS and skip setting LDFLAGS in config.mk some exes don't get the subsystem switch, and dlls get subsystem windows. The dll thing probably isn't a big deal, but the default should really be console for those. Test exes though would need to run on xp, so they have to have the subsystem directive. Using LDFLAGS vs DSO_LDOPTS seemed to get everything right.

Ahmed Aly

Comment 148

•

12 years ago

vs2012 update 1 has added support for targeting xp with c++ compiler is it necessary to continue working on this bug given that metro builds of firefox will need to move to vs2012 ?

jfwfreo

Comment 149

•

12 years ago

Yes it is necessary to continue with this, this bug is about making the changes to the build system so that when you compile Firefox (and other Mozilla projects) with Visual Studio 2012 Update 1 (with the XP support), the binaries that are produced will run on Windows XP.

(no longer active)

Comment 150

•

12 years ago

I think this bug has served its purpose. We now know all we need to know.

Status: NEW → RESOLVED

Closed: 12 years ago

Resolution: --- → FIXED

Jim Mathies [:jimm]

Reporter

Updated

•

2 years ago

Flags: needinfo?(jmathies)

missing exports 13 years ago Jim Mathies [:jimm] 41.56 KB, text/plain		Details
system apis 13 years ago Jim Mathies [:jimm] 400 bytes, text/plain		Details
typical dependency graph 13 years ago Jim Mathies [:jimm] 1.68 KB, text/plain		Details
msvc 10 redist.txt 13 years ago Jim Mathies [:jimm] 7.12 KB, text/plain		Details
2011 beta license 13 years ago Jim Mathies [:jimm] 68.49 KB, text/html		Details
msvcr110.dll/msvcp110.dll imports used by Firefox 12 years ago jfwfreo 13.97 KB, text/plain		Details
symbols in CRT libraries referenced by Firefox code 12 years ago jfwfreo 19.23 KB, text/plain		Details
Build system edit to build for XP 12 years ago Mark Straver 4.84 KB, patch		Details \| Diff \| Splinter Review
Changed batchfile (added MOZ_MAXWINSDK) 12 years ago Mark Straver 2.74 KB, text/plain		Details
xp compat build 12 years ago Jim Mathies [:jimm] 6.44 KB, patch		Details \| Diff \| Splinter Review