On 1/31/2011 12:17 PM, Mladen Turk wrote: > On 01/31/2011 06:20 PM, William A. Rowe Jr. wrote: >> On 1/31/2011 9:55 AM, Mladen Turk wrote: >>> >>> There is a solution to use DDK7.1 >>> It can create binaries that links to MSVCRT, however >>> this works for XP+ only. >> >> Which works... provided we continue on the makefile approach or use msbuild. >> Note that openssl encourages exactly this solution, and goes out of their way >> to avoid msvcrXX flavors. > > IDE is probably good enough for GUI apps, but that's just my > opinion. With each version it's a completely new environment, > and I personally see no point of using it for non-interactive projects. > Sure, debugger might be handy but think this is usable without > IDE dependency.
...outside of which, windbg is a much better solution for gathering the kinds of details we are interested in, without having to document a dozen different development environments :) >> There are now other reasons to avoid msvcrt.dll, given that the maintainers >> have declared msvcrt to be an OS component, and have declined to track C >> standards or portability. This is evidenced in their handling of *printf >> family of functions, which PHP folks have tripped over in awkward ways, and >> found no satisfaction reporting the issues to MS. > > This is marketing bs from ms IMHO. > They use msvcrt for "non-system" components as well like IIS and stuff. > Well I suppose they wish that treated to be "system" component > but then it executes the extensions from userland. > Now add multiple extensions/filters with various dll linkage and > you are just asking for trouble. I don't disagree it was a stupid call, but it is the reason for closing any legitimate cases related to posix or C language standards, and ends up adding risks when you are playing with user provided data. So at this point, it really is best avoiding going forwards, but unless you happen to hit on one of these bugs, it probably makes no difference for legacy builds. >> If anyone notices apr or httpd exchanging such resources in a way that would >> make httpd crash, we would *love* to know about it! This is the time for us >> to complete any corrections to the API, before httpd 2.4 ships. > > If we resist on using CRT stuff like strcpy_l/strcpy_s, _fstat64i32 and > other weirdness from contemporary CRTs, we'd be fine. Actually most of those date back to msvcrt.dll or have been added over the years. I was rather shocked while researching the i64 stubs of zlib to find that everything required is already in VC6/msvcrt.dll.
