Re: [MinGW-dvlpr] Msys & Mingw w32api Runtime Error (Was Re: Mingw Win32api Error)

[Paul G. <pga...@at...>]

> 
> 
> 1. You don't seem to understand the concept of an undocumented
> feature. I'm sure there are lots of functions in various system DLLs
> that are not described on MSDN, but if you use one of those functions
> then you can't blame anyone else when it gets removed and breaks your
> application. When NT 4.0 was released, GetLongPathName() was an
> undocumented function, so any software that expects to use it on NT
> 4.0 is broken and should be fixed.

	Ok.

> 
> 2. It is a great exaggeration to say that MinGW does not work for NT 4
> development. You are talking about ONE function, and an undocumented
> one at that.

	Perhaps...all I know is this, at this point, running an executable which has any reference to 
"GetLongPathNameA" will not work because according to the Windows Runtime Error, an entry point, 
"GetLongPathNameA" could not be found in kernel32.dll.

> 
> 3. Executables are not test cases. Source code can be compiled with an
> older version of w32api to check that thisactually didwork differently
> before. Is this one of your own applications, or one that is available
> on the web somewhere?

	It is a very large application/project for 3d Rendering which is OpenSource.

	I happen to be a developer for that project because it gives me the opportunity to test Mingw and Msys within 
the context of a complex project and a real world (or nearly so) environment.

	The CVS can be downloaded of course...but I can not see any reason why any of the developers (aside from 
myself) would have the time or energy to take on another project which is at least as complex (functionally and 
relationally speaking) as Msys and/or Mingw is.  Still, if anyone wants to the check it out, you can link to the home 
page at http://crystal.sourceforge.net/drupal/ or http://sourceforge.net/projects/crystal.

> 
> 4. The MSVC import libraries shlwapi.lib and kernel32.lib are just
> like the MinGW ones in that GetLongPathName is ONLY in kernel32.lib.
> Is this proof enough that you are not allowed to use the function on
> NT 4? Just because the function exists doesn't mean you are allowed to
> use it.

	I am not arguing that point.  What better way to do extreme testing on something though...?

> 
> 5. Even if there were two versions of libshlwapi.a (which there won't
> be), it would not make sense to choose one based on which OS you
> install MinGW on.

	Of course it wouldn't.

> The difference depends on the target platform, not
> the host platform (and the host may not even be Windows), but nobody
> wants to have separate libraries for different Windows targets because
> the headers should be able to handle that.

	Of course the different Windows targets should be able to handle that -- that is one of many points I have 
been trying to make.

	But what if they don't, as apparently is the case here?

> The guard that we just
> added to the header will prevent the program from compiling unless you
> specify that the source is for Win98/2000 (which is correct according
> to MSDN, MSVC, Borland C++ and every other source except the PSDK that
> you can't install).

	Ok.  (and the subtle insult/stab/assault/attack was not missed, nor was it appreciated -- I am not so dense as 
most folks here apparently want to believe that I am.  I do not "make up stories" nor do I "lie" about anything relative 
to my experience with anything.)

	Paul G.