Hi folks,

            Apparently I must restate a good deal of what to me has always been obvious, so forgive the length of this post as the length is directly contributable to the fact that I have felt I needed to restate what is, to me, pretty obvious, and not worth wasting the time of the collective intelligence of the developers.  Time is always a commodity.

  My focus here has always been on testing and running QA checks on various aspects of the Mingw and, most recently, the Msys distribution(s) (as well as the various distributions that are available, with a few exceptions, from the Mingw file downloads page).  I have made it a point not to say anything unless I could show, beyond doubt, that there is some sort of problem with some aspect of either the Mingw or the Msys distributions.

> Where's your test case?
>
> SDK says, declared in winbase.h so include windows.h.
> SDK says, Supported in Win98, WinME, Win2000 and WinXP.
> SDK says, That the library to use is kernel32.

(Why oh why must I fight every single time I find a verifiable and reproducible problem with Mingw, Msys or anything else related to Mingw and Msys and my ongoing testing of Mingw and/or Msys?)

            If what you are reporting is correct, Earnie, and I have no doubt that it is, at least as far as your version of the SDK is concerned, then please note that the SDK quotes(?) that you do reference do not mention NT4.  They only mentioned Win2k, WinXP and Win98/ME.

            I have already stated, numerous times, that this is happening under the NT4 OS.

            The "test case" or something that can be considered as a "test case" is this, I am using an NT4 OS.

            What may apply to Win2000, WinXP, Win98/ME does not always apply to NT4.

(All of those last three lines were, afaiac, far too obvious and seemed far too insulting to the collective intelligence of the folks on this mailing list to mention yet again -- now it appears I must restate the obvious.  That done, let's move on.)

            The SDK, in this case, is wrong by nature of the fact that it excludes any references, given what Earnie has posted above, to NT4.

(Also, in my perception, pretty obvious given the quotes that Earnie -- Thanks Earnie! -- did provide and not worth mentioning again out of my consideration and admiration of the collective intelligence of the developers here.)

            If anyone wants to see the .dlls, I think I can provide them, but, I am not at all sure how MS will feel about that.

            Alternatively, if anyone wants to create or somehow "establish" a "formal" test case, then anyone here can get on any NT4 OS, if they have one, and build something, preferably with the -mwindows switch enabled, using the latest release (w32-2.3.tar.gz) on their NT4 platform.

            If anyone can still do this, then they will have no doubt whatsoever that what I am trying to say here is as complete and accurate as it can possibly be.  Those same people will also be able to confirm, beyond the shadow of any doubt, that what I am stating here is true and is valid when it comes to Mingw and Msys under NT4.

            In the off chance that no one has an NT4 OS then someone will have to make a choice, decide to trust what I am saying is in fact the case, or choose to fight with me every step of the way in the vein hope of disprooving something that can not be disprooven.

            At the risk of yet again restating the obvious, the facts are as follows:

            The "GetLongPathNameA" and "GetLongPathNameW" entry points, for NT4 ("_WIN32_WINNT >= 0x0400"), are kept in shlwapi.dll.  They are not kept in kernel32.dll ("_WIN32_WINNT >= 0x0400").

            How can I make that any clearer?

            This is to say that Mingw (-mwindows switch enabled) no longer works (given current files included with the w32api-2.3.tar.gz) under the NT4 OS.

            How can I make that any clearer?

            I've shown proof of the fact that Mingw (-mwindows) no longer works for NT4.

            Since it is equally obvious that the libkernel32.a and libshlwapi.a are pretty much identical between Msys and Mingw, it means that Msys also no longer works under NT4 when -mwindows switch is enabled for the same reasons.

            I have also shown proof that the cause for neither Mingw or Msys working is directly contributable to the existence of two invalid .a files which are being generated and released as part of the w32api-2.3.tar.gz archive/distro or as part of the latest Msys release (1.09-2003.06.30-1).  Those files are: libkernel32.a and libshlwapi.a.

            A valid set of w32api .a files for NT4 would not be generating this error for the NT4 OS.

            A valid set of w32api .a files from the w32api-2.3.tar.gz would not be causing runtime errors under NT4.

            What else is necessary to understand in order to determine that there is a problem with the w32api-2.3.tar.gz distribution and the functioning of both Msys and Mingw when it comes to the NT4 OS?

            What else is necessary to understand about which (.a) files are at fault and why those particular (.a) files are at fault (in error) where the NT4 OS is concerned?

(me? frustrated?...nah...*wrong*)

            Paul G.