I pulled the NSS tree, compiled it, and tried to run the cmd tools. All I got was: "The application failed to initialize properly (0xc0000022). Click on OK to terminate the application." or (0xc0000142). The fix was to export the .manifest files to the bin directory too. Windows is quite alien to me, but maybe the real solution is to compile the manifest files inside the binaries when using VC++ 2005?

I believe that, at present, none of the NSS developers is using VC++ 2005. It seems like a step down from the older MSVC products that we're using. One of us is going to have to bite the bullet, I guess.

(In reply to comment #1) > I believe that, at present, none of the NSS developers is using VC++ 2005. > It seems like a step down from the older MSVC products that we're using. > One of us is going to have to bite the bullet, I guess. I hear lot of people complaining about it. It's not a hard fix. It's just a question of exporting the .manifest files too -- dunno what options to give to VC++ to get it to compile it in, but I can help since I'm stuck with that version :)

Feel free to submit a patch

This is just the patch from bug 249782. I've applied it to NSS 3.11.3, and it solves the problem for me.

Comment on attachment 239634 [details] [diff] [review] Manifest patch I have several concerns about this patch. It may be *close* to the right answer, but it needs a little adjustment first. 1) Main issue: ifdef MSMANIFEST_TOOL issues MSMANIFEST is set to 1, even on Windows systems that don't have MSVC 2005. Perhaps it should be set conditionally based on the presence of the right version of msvc. 2) manifest tool name conflicts mt.exe already exists on my system. If executed on my system, this would run the MKS "mag tape" program (Yes, My windows system has a tape drive). So rather than hard-coding mt.exe into the makefile in numerous places, a make variable should be used for that program name, so that it can be overridden (perhaps with a full path name to that executable). Maybe the Makefile/script should try to construct a path name to mt.exe that finds it where cl.exe lives (if that's the right place), to ensure that it never runs the mag tape program. 3) silent operation undesirable (lose the "@") The make output log should show all the commands that happened. It should not hide the execution of the commands that test for the presence of the manifest file and then run the manifest tool.

(In reply to comment #5) > (From update of attachment 239634 [details] [diff] [review] [edit]) > I have several concerns about this patch. It may be *close* to the right > answer, but it needs a little adjustment first. > > 1) Main issue: ifdef MSMANIFEST_TOOL issues > MSMANIFEST is set to 1, even on Windows systems that don't have MSVC 2005. > Perhaps it should be set conditionally based on the presence of the right > version of msvc. Well, all three places check for the existence of a .manifest file, and only then run the mt.exe tool. Is it not a reasonable assumption that if it is there, it should be compiled in? The ifdef then only runs it on WIN32 systems. > 2) manifest tool name conflicts > mt.exe already exists on my system. If executed on my system, this would > run the MKS "mag tape" program (Yes, My windows system has a tape drive). > So rather than hard-coding mt.exe into the makefile in numerous places, > a make variable should be used for that program name, so that it can be > overridden (perhaps with a full path name to that executable). Sure. Combined with the above, the same variable can be used. > Maybe the Makefile/script should try to construct a path name to mt.exe > that finds it where cl.exe lives (if that's the right place), to ensure > that it never runs the mag tape program. It's a fair point, but is this really a problem for the build system. If you have another tool called cl.exe in your path, is that not your problem? The makefile could include a check, but then I'm really on foreign ground. Is there a Windows equivalent of 'dirname mt.exe', or is it the "perl way"? > 3) silent operation undesirable (lose the "@") > The make output log should show all the commands that happened. > It should not hide the execution of the commands that test for the > presence of the manifest file and then run the manifest tool. Other places in rules.mk also uses silent mode, but it's the same to me :-)

Comment on attachment 240450 [details] [diff] [review] Patch v2 r=nelson Wan-Teh, do you concur?

So, I wonder... where do this patch go? Just to trunk? Then I'll check it in.

Bug 353475. When building NSS with MSVC 2005, use the "mt" command to embed the manifest files into the executables and DLLs. Patch contributed by Allan Beaufour <allan@beaufour.dk>, r=nelson,wtchang Checking in WIN32.mk; new revision: 1.22; previous revision: 1.21 Checking in rules.mk; new revision: 1.70; previous revision: 1.69 Will apply this patch to the NSS_3_11_BRANCH after it bakes on the trunk for a bit (and Tinderbox is happy).

Committed on NSS_3_11_BRANCH. Checking in WIN32.mk; new revision: 1.20.2.2; previous revision: 1.20.2.1 Checking in rules.mk; new revision: 1.66.2.3; previous revision: 1.66.2.2