Microsoft Header Bingo

Wednesday, April 16th, 2008
atlbase.h
(ATL)

oleacc.idl
(Accessibility IDL)

wpcapi.h
(Windows Vista Parental Controls)

CRT sources
(optional, needed for jemalloc)

Notes
VC++8 Express (needs separate SDK) No

No

No

No
VC++8 Professional with SDK

Yes

Yes

No

Yes
Windows 2003R2 SDK

Yes

Yes

No

No
Windows Vista SDK (6.0)

No

No

Yes

No
Windows 2008 SDK (6.1)

No

Yes

Yes

No

MozillaBuild doesn’t detect the presence of this SDK (yet)
VC++9 Express (needs separate SDK) No

No

No

No

Neither VC9 version builds Mozilla correctly yet: they embed duplicate/incorrect manifests by default
VC++9 Professional with SDK

Yes

Yes

Yes

Yes

Developers were trying to build Mozilla on Windows and having failures 75% of the way through the build process, with error messages about missing headers. Depending on their configuration, any of the headers listed above may have been missing. I know MS tries: this is not malicious breakage on their part, just a side effect of releasing very complex systems. But boy can it be frustrating at times. Right now we’re in a situation where you can’t build Firefox using free tools and only a single SDK, because the newer SDKs don’t have ATL and the older SDKs don’t have wpcapi.h for Windows Vista parental controls.

To fix the problem, you need to install both the Windows 2003 SDK and the Windows Vista SDK. Ted Mielczarek is working on doing a quick release of MozillaBuild 1.2.1 which will support loading multiple SDKs into your build environment. Until then, there are some custom start scripts available.

I also added some configure checks so that we can detect the absence of these header files when you first start building. This will hopefully reduce the pain and wasted developer hours futzing with headers and build environments and trying an hourlong build process again to “see what happens”.

Patching the Windows CRT

Thursday, January 10th, 2008

Stuart has been working on using an allocator for Mozilla which has much better performance characteristics, especially with memory fragmentation and heap growth over time. The allocator he chose is jemalloc, the default allocator for the FreeBSD libc. On Linux, intercepting and replacing malloc is fairly easy, because of the way dynamic symbol loading works. On Windows, however, it is difficult or impossible to intercept and redirect calls to malloc to a custom allocator. So instead of trying to hook to a prebuilt CRT, I spent most of today hacking the Windows C runtime (CRT), replacing the default allocator with jemalloc.

The Windows CRT sources come with VC8 professional edition so any licensed user may hack on them and redistribute the result as part of a larger program. It comes with a mostly-working nmakefile1: I had to disable the code which builds the managed-code CRT because apparently I don’t have the right .NET headers installed. Getting the new jemalloc.c file to build wasn’t that hard, either: it required a few #defines, typedefs, and disabled warnings, but nothing serious. The hardest part about replacing It was figuring out what parts of the original CRT were heap-related and removing them correctly. It was a wild ride, but I think that I have a build of the Windows CRT that works… at least small programs like xpidl and shlibsign work.

Unfortunately, according to the EULA2 I am not allowed to redistribute this modified CRT by itself. So the only way you can get it is by distributing it with a Firefox build. Also, I’m not allowed to post the patch queue which I used to develop the custom CRT, because those patches may contain copyrighted code in context. Do any of my readers know of a format that will alter a set of files according to a set of instructions without the instructions revealing the contents of the original files? I would really love it if Microsoft would release their C runtime code under a liberal open-source license… can someone suggest a good person to contact at Microsoft?

Stuart will have some builds posted soon, once a few kinks get ironed out.

For Mozilla2 we’re probably going to push the solution to an intermediary library: we will have a single allocator library which is used for both garbage-collected (managed) and explicitly allocated/freed (unmanaged) memory. We will switch back to the standard CRT, but we will try to avoid using the standard CRT allocator at all. See the “space management” thread on the tamarin-devel mailing list (December and January) for some background discussion.

  1. nmake is one of the suckiest build systems on the planet. I could get better results with a .vbs.
  2. From the EULA, section 3.1: …you agree: (i) except as otherwise noted in Section 2.1 (Sample Code), to distribute the Redistributables only in object code form and in conjunction with and as a part of a software application product developed by you that adds significant and primary functionality to the Redistributables…