William A. Rowe, Jr. wrote: > Mladen Turk wrote: >> Since all this is a hack, IMHO we can simply exploit the >> feature from DLL apr build, and leave the current >> status for LIB builds like it was before. >> (BTW, my patch does that). > > Given the choice between supporting all architectures except amd64, or > supporting only .dll's, I vote for the former. That's -1 to the code > living in trunk. > > The DLL thing is a 'hack' - something that doesn't solve the whole issue > but works around the problem in front of you. The CRT linkage is by design > in the PE format, the only hacks needed are to resolve why certain PE flavors > are being handled differently than others, and writing the #if arch logic > to handle this or leave it unresolved for an architecture. > > Native-64 is going to seriously underperform 32 bit compilations for 95% of > applications in the first place. But it's entirely reasonable (and common) > for developers to decide to roll out a monolithic .exe binary.
One more thought on the Native-64 issue; this is SUPPOSED to be supported by the Windows PE format. Either we did something wrong or it's a bug in the compiler (and since they are soliciting feedback for SP1 it's a good thing to point out, I'll see if we can't fast track it.) But my point is that the THREAD_DETACH solution covers 1/2 the cases, and the PE solution solves 100% of the cases, sans bugs. > Other opinions before Mladen or I proceed? I'm not happy with the silence here... feedback please? There's another issue - we've been debating a 'fix' without any test case, and really can't have a code shootout without some test case in place that validates the two possible solutions. Bill
