Windows API calls that don't work? (Was RE: Stupid stupid question :/)

Windows API calls that don't work? (Was RE: Stupid stupid question :/)

[Colin Peters]

A. Phillip Smith[SMTP:asmith@www.aeinc.com] wrote:
[snip]
>of fact that the mere INCLUSION of a particular Win32 call caused the
>GUI portion of a program to apparently fail (silent death). Note that
>the code was NEVER invoked, as I stated, so usage errors are not at
>issue. 
>
>This is further complicted on Windows NT by the fact that unless you strip
>the executable, the binary will not run. Hence you have no VCC++ debugging OR
>gdb debugging capability. Here's another simple program in it's entirety.
>Compile it per the gcc line. It works fine. Now uncomment the statement
>containing the GetFullPathName call, and rebuild. If you get something
>other than the "silent death" behaviour, please share it. This seems like
>a bug to me, unless there's some other link options of which I'm unaware...
[snip - Code example]

It doesn't seem to be a code generation problem, or at least not an easy
one to reproduce. I must point out that I compiled with Mingw32 and not
the normal Cygnus libraries, so there is some chance (small though it may
be) that the Mingw32 environment removes or influences this bug in some
strange way. Another possibility is that it is an NT thing, since I did
the compile on 95 (where you don't have to strip to get a working exec
either, so debugging is possible with GDB). Anyway the point is that it
works, both ways, no problem. (The compile line under Mingw32 is slightly
different, but essentially comes down to the same arguments for cc1 and
ld).

Are you using a completely vanilla version of GNU-Win32 or have you made
changes to things (like the startup code for example)? Could you send me
a copy of your silently failing binary?

Colin (If it is a compiler bug lets find it and fix it) Peters.

PS. Any confirmations on that statement about NT from other readers?
    Does stripping an executable make it work? Do you *have* to strip
    on NT? Is there a difference between the -s link option and using
    strip after linking?

-- Colin Peters - colin@bird.fu.is.saga-u.ac.jp
-- Saga University Dept. of Information Science
-- http://www.fu.is.saga-u.ac.jp/~colin/index.html
-- http://www.geocities.com/Tokyo/Towers/6162/

-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Windows API calls that don't work? (Was RE: Stupid stupid question :/)

[Fergus Henderson]

Colin Peters, you wrote:
> 
> PS. Any confirmations on that statement about NT from other readers?
>     Does stripping an executable make it work? Do you *have* to strip
>     on NT? Is there a difference between the -s link option and using
>     strip after linking?

In my experience executables that are not stripped at all work fine.
My experience was that building with the `-s' option on either Windows
95 or NT produced executables that would not run on NT.  There is a
difference between using the `-s' link option and using strip after
linking; in my experience the latter worked on NT, while the former
didn't.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Windows API calls that don't work? (Was RE: Stupid stupid question :/)

[Jim Balter]

Colin Peters wrote:
> 
> A. Phillip Smith[SMTP:asmith@www.aeinc.com] wrote:
> [snip]
> >of fact that the mere INCLUSION of a particular Win32 call caused the
> >GUI portion of a program to apparently fail (silent death). Note that
> >the code was NEVER invoked, as I stated, so usage errors are not at
> >issue.
> >
> >This is further complicted on Windows NT by the fact that unless you strip
> >the executable, the binary will not run. Hence you have no VCC++ debugging OR
> >gdb debugging capability. Here's another simple program in it's entirety.
> >Compile it per the gcc line. It works fine. Now uncomment the statement
> >containing the GetFullPathName call, and rebuild. If you get something
> >other than the "silent death" behaviour, please share it. This seems like
> >a bug to me, unless there's some other link options of which I'm unaware...
> [snip - Code example]
> 
> It doesn't seem to be a code generation problem, or at least not an easy
> one to reproduce. I must point out that I compiled with Mingw32 and not
> the normal Cygnus libraries, so there is some chance (small though it may
> be) that the Mingw32 environment removes or influences this bug in some
> strange way. Another possibility is that it is an NT thing, since I did
> the compile on 95 (where you don't have to strip to get a working exec
> either, so debugging is possible with GDB). Anyway the point is that it
> works, both ways, no problem. (The compile line under Mingw32 is slightly
> different, but essentially comes down to the same arguments for cc1 and
> ld).
> 
> Are you using a completely vanilla version of GNU-Win32 or have you made
> changes to things (like the startup code for example)? Could you send me
> a copy of your silently failing binary?
> 
> Colin (If it is a compiler bug lets find it and fix it) Peters.
> 
> PS. Any confirmations on that statement about NT from other readers?
>     Does stripping an executable make it work? Do you *have* to strip
>     on NT? Is there a difference between the -s link option and using
>     strip after linking?

Under NT 4.0, the program dies just by virtue of *referencing*
GetFullPathName, without calling it (as APS said).  The following
is enough to cause the access violation:

  #include <windows.h>

  void (*xxx)() = GetFullPathName;

  int STDCALL
  WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow)
  {
        return 0;
  }

I've tracked this down, and have determined that it dies with a SIGSEGV
which doesn't get printed anywhere because cygwin.dll prints it to
STD_ERROR_HANDLE, which isn't valid.  Clearly it should do better,
at the very least writing it to the strace output if that is a file, and
a
MessageBox would be nice.  A useful option would be to not set the
exception handler, so that the windows debugger would get it.
APS' complaint that silent exit is a bug is quite valid, but it isn't
something to be surprised about from alpha software like cygwin.dll.

The point at which it dies is the at the very beggining of main()
from libcmain.cc, when it calls GetModuleHandle.  That call goes to a
jump instruction that goes
through an indirect pointer that appears to contain the wrong
address, since it is the address of some code.  The jump uses the
content of that code as the "location" to go to, and so it
dies.  Perhaps to someone who knows about Windows dll's and jump tables,
the problem here might be obvious, but I know nothing of those things.
But it sure looks like a serious screwup by ld.

If someone wants to pursue this who can run the MS debugger under NT
4.0,
the easiest way is to build a version of cygwin.dll with the
init_exceptions call in dcrt0.cc commented out (or ignored based
upon an environment variable, so you can control it dynamically).


A word about the comments from drs@inxpress.net:

>>... I merely stated a point
>> of fact that the mere INCLUSION of a particular Win32 call caused the
>> GUI portion of a program to apparently fail (silent death). Note that
>> the code was NEVER invoked, as I stated, so usage errors are not at
>> issue.
>
> I would have to see this to believe it.

He gave an example.  His WinMain never gets called,
let alone the GetFullPathName call that triggers the problem.

>> Compile it per the gcc line. It works fine. Now uncomment the statement
>> containing the GetFullPathName call, and rebuild. If you get something
>> other than the "silent death" behaviour, please share it. This seems like
>> a bug to me, unless there's some other link options of which I'm unaware...
>
> The code you posted failed to work as expected, Phillip, because you 
> are not using it correctly. What you posted works exactly as advertized
> by the SDK. The API puts the path and the file-name together. That's it.
> It does not verify the presence of the file name. It is not a "search" 
> api at all. Granted, this is a pretty stupid behaviour, but then I'm not 
> an MS apologist. The API in question works correctly and compiles
> correctly
> under gnu-win32. You simply don't know how to use it.

Your arrogance is unwarranted and unearned.
His usage was perfectly reasonable, even if his comment that refers to
"search" is misleading.  In any case, his use or misuse is irrelevant
when the complaint was that the code died silently.  There is nothing
in any SDK that would indicate that MessageBoxes should never show up,
with not even a Dr. Watson popup.  The fact that the code works as
advertised on *your* system is irrelevant when the behavior of the code
on *APS's* system was described ("silent death") and is incorrect.

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Windows API calls that don't work? (Was RE: Stupid stupid question :/)

[Chin Chee-Kai]

I am not sure the talk about "unstripped binaries don't run on
WinNT" is applicable in general.

I've got Mingw32 installed on b17.1 WinNT4.0.  But there was
no problem running unstripped or stripped executables.  Is your
reference on Win3.51 or a very specific stress-test program?

BTW, stripped *.o files still don't compile up to an executable
(this works on Unix alright).   I got:
  C:\cygnus\H-i386-..../lib/libcygwin.a(libcmain.o): In function
	`main':
	/pizza/mushroom/noer/beta17/src/winsup/libcmain.cc:30:
	undefined reference to `WinMain@16'

==> "strip.exe" overstripped.



Chin Chee-Kai (Last, First)
Internet Email-ID:	cheekai@gen.co.jp



On Mon, 24 Mar 1997, Colin Peters wrote:

> >A. Phillip Smith[SMTP:asmith@www.aeinc.com] wrote:
> >
> >[...snipped...]
> >
> >This is further complicted on Windows NT by the fact that unless you strip
> >the executable, the binary will not run.
>
> [...snipped...]
> 
> PS. Any confirmations on that statement about NT from other readers?
>     Does stripping an executable make it work? Do you *have* to strip
>     on NT?

-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Windows API calls that don't work? (Was RE: Stupid stupid question :/)

[A. Phillip Smith]

> 
> Fergus Henderson wrote:
> 
> In my experience executables that are not stripped at all work fine.
> My experience was that building with the `-s' option on either Windows
> 95 or NT produced executables that would not run on NT.  There is a
> difference between using the `-s' link option and using strip after
> linking; in my experience the latter worked on NT, while the former
> didn't.
> 
> -- 

I never use the '-s' option, or strip before linking. I've built over
two dozen stand alone GUI applications and example programs from the SDK and
seen the same behavior. The NT versions never run unstripped, and Win95
always runs strippped or unstripped. This is with cygwin, and not mingw,
which I understand does not exhibit this behaviour.

Phil Smith
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Windows API calls that don't work? (Was RE: Stupid stupid question :/)

[Gunther Ebert]

Colin Peters wrote:
> 
> PS. Any confirmations on that statement about NT from other readers?
>     Does stripping an executable make it work? Do you *have* to strip
>     on NT? Is there a difference between the -s link option and using
>     strip after linking?
> 

My experiences with gnu-win32-produced binaries on NT 4.0 are:
- gcc -s is different from strip (strip produces a working binary
  while gcc -s doesn't). 
  This statement isn't true for dlls or any binaries containing a 
  .reloc section. For binaries containing a .reloc section strip 
  doesn't work either.
- there is no need for stripping binaries which don't contain
  resources.
- binaries containing resources have to be stripped to get them
  working (NT 4.0 'feature')
  OR
  they have to get a .reloc section 
- gdb crashes when loading a gnu-win32-produced executable containing 
  a .reloc section (currently you cannot debug any programs containing
  resources)
- gdb doesn't crash when loading any program containing a .reloc section
  which isn't produced by gnu-win32 (in other words, you can load
  notepad into gdb and it doesn't crash)
- dll relocation doesn't work in some cases, this problem is hard to
  reproduce, it seems to apply to bigger dlls

I hope this helps to find the Bad Binary Bug.
-- 

Gunther Ebert
iXOS Anwendungs-Software GmbH
Angerstrasse 40-42
D-04177 Leipzig

Phone : +49 341 48503-0
Fax   : +49 341 48503-99
E-mail: mailto:gunther.ebert@ixos-leipzig.de
www   : http://www.ixos-leipzig.de
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Nobody in the world understands Gnu's 'ld'.

[root]

Jim wrote:
> 
>   void (*xxx)() = GetFullPathName;
> 
>   int STDCALL
>   WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow)
>   {
>         return 0;
>   }
> 
> I've tracked this down, and have determined that it dies with a SIGSEGV
> which doesn't get printed anywhere because cygwin.dll prints it to
> STD_ERROR_HANDLE, which isn't valid.  Clearly it should do better,
> at the very least writing it to the strace output if that is a file, and
> a
[snip]
> 
> The point at which it dies is the at the very beggining of main()
> from libcmain.cc, when it calls GetModuleHandle.  That call goes to a
> jump instruction that goes
> through an indirect pointer that appears to contain the wrong
> address, since it is the address of some code.  The jump uses the
> content of that code as the "location" to go to, and so it
> dies.  Perhaps to someone who knows about Windows dll's and jump tables,
> the problem here might be obvious, but I know nothing of those things.
> But it sure looks like a serious screwup by ld.

A dll call under windows (NT or 95) is just a jump through a
table of pointers to functions. This table (called 'import table')
is built by the linker. 

The linker builds this table by using an 'import library'. That
library contains several small pieces of code and special
sections that, when combined together with some pieces of
code in the startup (the famous .idata$3 section) will build
that import table in the executable.
This is an extremely complex and error prone process, that costed
me months of horrible work when I wrote the linker for my
system. I was VERY happy when it was over...

Gnu's linker: A NIGHTMARE!
-------------------------

Since several months people here report that Cygnus's linker is flawed.
I think that it is just plain that Cygnus doesn't have the
know-how to repair it, since Steve Chamberlain, the guy that
wrote most of it, hasn't posted anything here since ages and
he was very active before.

Before writing my linker, I studied gnu's linker code with the
naive assumption that I could use it. After spending weeks and weeks
trying to understand it, I gave up and wrote mine.

There is only ONE person in the world that understands that code
and he is called Steve Chamberlain. If Cygnus doesn't have
him any more, users of gnu-win32 will have to live with a flawed linker
for the rest of their lives.

Just to give you an idea, ld is supposed to link an object file
from sun's unix format with some code from windows 95 and with
some code of hp Unix. Of course this is ridiculous and it will never
work, but this is how 'ld' is designed: an incredible complexity
that (to me) seems completely unwarranted. It has a full blown LANGUAGE
(with lex+yacc parser/lexer!) that is supposed to recognize linker
commands. Obviously nobody ever uses it, but to understand
what the linker is doing you have to go through yet another layer
of complexity.

Then you have the 'BFD' format, that is supposed to be an universal
binary format designed by GNU that will abstract the binary format
of all machines in the western world into ONE format. Obviously
it doesn't work, but then you have not only to understand what
binary format you have in windows (what is difficult enough) but
you have to understand BFD too.

And then you have the macro-sickness... You read:
	a = foobar(b->field);

Well, where is foobar? Nowhere. It is a macro that will be expanded
into an index into a table using b. Mmmm. This table is
actually an table of tables. MMMMMMMMMMM. OK let's go on.
In that table of tables you have a field that is a table of
functions. GOD! WHATS THIS!!! But let's go on. That table
of functions is indexed by that b->field to jump into ???
IT DEPENDS OF THE RUNTIME CONDITIONS. Of course! You can at
the linker command line change the output format remember?
You can link your windows object files to give a SUN OS
executable isn't that FUN???

And to crown this beatiful construction there is NO DOCUMENTATION
whatsoever about anything I have told you in this message. I inferred
this from reading THE C CODE!!!

Not surprisingly, Cygnus is stuck with a linker that nobody 
in the world understands... except Steve of course. But I think
*even he* has problems to know what the hell is going on in there...

That is why this linker can't even recognize MSVC object code
format and use the MSVC .LIBs. Because nobody in the world
is able to modify it. Of course we do not need compatibility
with SUN or HP Unix under Windows 95. We would need MSVC
compatibility. But to do that we would have to find somebody
that understands 'ld'...

I think that anybody using 'ld' is living very dangerously...

-- 
Jacob Navia	Logiciels/Informatique
41 rue Maurice Ravel			Tel 01 48.23.51.44
93430 Villetaneuse 			Fax 01 48.23.95.39
France
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Tim Iverson]

Actually, quite a few people understand GNU's ld very well indeed (I do,
for one, and I suspect the folks at Cygnus understand it much better).  And
yes, I not only use the scripting language, I rely on it quite heavily.  It
is indispensable when preparing images for an embedded system.

I've also linked disparate object formats with GNU-ld, and for the formats
it supports, it usually works quite well.  Of course, I usually also
manually inspect the output for the first couple of images ... ;-)

The only problem I've come across with the NT/95 b17.1 GNU ld was the
screwed up offsets when linking OMF and GNU-pe-i386 objects with a
commercial linker.  I had assumed this was a Phar-Lap problem or just an
incompatible image problem -- I'm a little out of date wrt. MS; didn't know
MS' "PE" really was COFF+MS (thanks for info win32-folks ;-).  There are
other reports of the same problem with the MSVC linker, though.  So, I now
suspect a minor bug in the GNU implementation of pe-i386.

BTW, before you start throwing around all these assumptions about what 'we'
need in a linker, consider that I would indeed prefer support for a.out,
ELF, and other Unix object formats over support for linking MSVC objects or
libraries.  That would be a feature I would use.  Linking with MSVC objects
would be a feature I would not use.  GNU-ld is one of the major attractions
to using the GNU toolset.  The implementation has it's drawbacks, but overall
it is a rather large step forward in the linking game.

The whole GNU concept is driven by people who need a feature bad enough to
actually implement it, and generous enough to share the results of their
efforts.  Whine all you want, but be aware that mostly it just irritates
the folks that spend time writing useful code.

I may take a stab at fixing the offset problem.  But since this feature
would only be used for a limited time here, I won't waste more than a few
hours on it.  If you really need this feature, don't hold your breath for a
patch from me.

Damn, anyone got a pair of pliers?  I seem to have this trolling hook
stuck in my mouth ... ;->


- Tim Iverson
  iverson@cisco.com

\f
+----------------
| From: root@jacob.remcomp.fr (root)
| Subject: Nobody in the world understands Gnu's 'ld'.
| To: jqb@netcom.com (Jim Balter)
| Date: Tue, 25 Mar 1997 08:23:33 +0100 (MET)
| Cc: gnu-win32@cygnus.com
| 
| Gnu's linker: A NIGHTMARE!
| -------------------------
| 
[very long anti-GNU-ld diatribe, heavily paraphrased: I can't comprehend
 GNU ld, therefore I gave up and wrote my own linker.  No one ever uses
 half the features of GNU ld anyway.  All we really need is MSVC object
 and library support.]
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Stupid stupid remarks

[Jim Balter]

DRS wrote:
> 
> Jim Balter wrote:
> 
> > Under NT 4.0, the program dies just by virtue of *referencing*
> > GetFullPathName, without calling it (as APS said).
> 
> Huh. Must be a bug in the linker. (Not.)

It is, and I've proven it.

> The following code compiles and works correctly under win95.

It has been proven that Win NT misbehaves in cases where win95 does not;
ld -s is a well-known example.

> // g++ -o test.exe test.cpp

This has nothing to do with the bug being discussed.

> So even though you and Phil claim to have found a linker bug, I have
> yet to be able to reproduce it.

So what?  You haven't run the same code, nor on the same system.

> The correct prototype for GetFullPathName looks like this, Jim:

Well known to me, but irrelevant.

> Perhaps. But my code seems to work, while yours and Phil's doesn't. ;)

Which of course is not the point.  But in fact, Phil's code works
if -lkernel32 is omitted from the command line.

> Regards as always.

Not from me.

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Nobody in the world understands Gnu's 'ld'.

[Fergus Henderson]

Jacob Navia wrote:
> 
> Gnu's linker: A NIGHTMARE!
> -------------------------

... followed by a lot of nonsense and one good point.

> Since several months people here report that Cygnus's linker is flawed.
[...]
> Before writing my linker, I studied gnu's linker code with the
> naive assumption that I could use it. After spending weeks and weeks
> trying to understand it, I gave up and wrote mine.
[...]
> Just to give you an idea, ld is supposed to link an object file
> from sun's unix format with some code from windows 95 and with
> some code of hp Unix. Of course this is ridiculous and it will never
> work, but this is how 'ld' is designed: an incredible complexity
> that (to me) seems completely unwarranted.

As others have noted, the features that you complain about _are_
highly desirable and people do use them.

> And then you have the macro-sickness... You read:
> 	a = foobar(b->field);
> 
> Well, where is foobar? Nowhere. It is a macro that will be expanded
> into an index into a table using b. Mmmm. This table is
> actually an table of tables. MMMMMMMMMMM. OK let's go on.
> In that table of tables you have a field that is a table of
> functions. GOD! WHATS THIS!!! But let's go on. That table
> of functions is indexed by that b->field to jump into ???
> IT DEPENDS OF THE RUNTIME CONDITIONS.

This sort of programming -- emulating C++ virtual functions in C -- is
a pretty common idiom (e.g. the Linux kernel uses similar techniques).
I didn't find it difficult to understand.

> And to crown this beatiful construction there is NO DOCUMENTATION
> whatsoever about anything I have told you in this message.

This is Jacob Navia's one good point.

It does seem to me that the authors of GNU ld
don't really have much idea about software engineering.
For example, there are some functions in there that are
thousands of lines long.  Yes, that's right, 5000 lines
of code, all of it a single C function.

Documentation and proper structuring of code should NOT be
after-thoughts.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

API's that certainly do work. [was; Re: Windows API calls that don't work? (Was RE: Stupid stupid question :/)

[DRS]

Jim Balter wrote:

> Under NT 4.0, the program dies just by virtue of *referencing*
> GetFullPathName, without calling it (as APS said). 

Huh. Must be a bug in the linker. (Not.)

The following code compiles and works correctly under win95. I suggest 
it may work on your system, too.

// g++ -o test.exe test.cpp  

#include <windows.h>
#include <iostream.h>
	
LPTSTR lpFilePart;
                   
main()
{
	DWORD (*api)( LPCTSTR file, DWORD length, 
			LPTSTR buf, LPTSTR *lpFile);  
	api = GetFullPathName;
	char* lpFileName = "test.exe";
	char* buffer = new char[256];
	 (*api)(lpFileName, 256, buffer, &lpFilePart); 
	cout << "buffer: " << buffer << endl;
	cout << "filename: " << lpFilePart << endl;
	delete [] buffer;
	return 0;              
}

So even though you and Phil claim to have found a linker bug, I have
yet to be able to reproduce it. The function works correctly 
either referenced as a pointer, or simply on it's own. I don't know 
why you are trying to reference the function name (it has nothing to
do with calling the api) but you brought it up. I can find no trace 
of the problems you guys describe. All of the API's mentioned work
fine for me. So *maybe* it's an NT thing. 

Maybe not.


> The following is enough to cause the access violation:
> 
>   #include <windows.h>
> 
>   void (*xxx)() = GetFullPathName;
> 

The correct prototype for GetFullPathName looks like this, Jim:

DWORD (*api)( LPCTSTR file, DWORD length, LPTSTR buf, LPTSTR
*lpFilePart);  
        
[...]
> Your arrogance is unwarranted and unearned.

Perhaps. But my code seems to work, while yours and Phil's doesn't. ;)

>There is nothing
> in any SDK that would indicate that MessageBoxes should never show up,
> with not even a Dr. Watson popup.  The fact that the code works as
> advertised on *your* system is irrelevant when the behavior of the code
> on *APS's* system was described ("silent death") and is incorrect.

I hate to disagree. I can only mention many hours of frustration in the
old win16 days, trying to figure out why an app silently failed.

If my code sample fails on your system (or Phils) then I will be happy
to
agree--something is wrong with the linker or perhaps the NT version of
the function. On the other hand, if it works under NT, then I hope
and expect you to acknowledge as much. Everyone makes mistakes 
in their code, but not all of us immediately blame the toolset for 
our problems. 

Regards as always.
--DRS
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Balter's InCivility Does Not Equal a Bug in ld [was: Re: Stupid stupid remarks

[DRS]

Jim Balter wrote:

> It has been proven that Win NT misbehaves in cases where win95 does not;
> ld -s is a well-known example.

Yes, as I said, it might be an "NT thing." But what does this have to do
with
the GNU linker? If the problem is NT related then you should be
complaining
to microsoft. Maybe the API's in question are not even supported equally
across win95/NT. This is a distinct possibility, since one (the
WriteProfileSection)
is depricated for win32 apps, and the other is a hack no professional
would
likely need.

> > // g++ -o test.exe test.cpp
> 
> This has nothing to do with the bug being discussed.

Wrong. You and Phil claimed the linker failed to handle certain API's. I
have attempted to verify this and found the opposite. You claim to have
proven
there is a bug in the linker, but the only code you posted to demo this,
turned out not to even compile, much less link. Instead of ad hominum 
attacks, you might try posting code which proves your point. 
The code *I* posted works correctly whether you use 
"g++ -o test.exe -mwindows --subsystem,windows" or not.  

> > So even though you and Phil claim to have found a linker bug, I have
> > yet to be able to reproduce it.
> 
> So what?  You haven't run the same code, nor on the same system.

Well, I'm using the same linker, which is building the same NE
executable,
using the same API's, and the code you and phil have provided--after
correcting your errors, of course. What more do you want? 
 
> > The correct prototype for GetFullPathName looks like this, Jim:
> 
> Well known to me, but irrelevant.

If it was known to you, then why did you prototype the function pointer
incorrectly? Why did you post code that would not even compile? And why
claim "merely referencing the function is enough to cause the problem"?
When it plainly is not?

> > Regards as always.
> 
> Not from me.

Your lack of civility is amusing. But it proves nothing more than 
your general status as Unix oaf and Windows wanna-be. 

--DRS
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: DRS's incivility

[Jim Balter]

DRS wrote:
[various falsehoods snipped]

> Your lack of civility is amusing. But it proves nothing more than
> your general status as Unix oaf and Windows wanna-be.

into my killfile.

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Stupid stupid remarks

[Eric Bovell]

On 26 Mar 97 at 18:05, DRS wrote:

> Your lack of civility is amusing. But it proves nothing more than 
> your general status as Unix oaf and Windows wanna-be. 

I originally thought I might get something useful out of this mailing
list (and maybe even be able to contribute a bit).  Most
technically-specific mailing lists tend to be civil, intelligent,
and generally enlightening. But the realization that someone like DRS
is continuously insulting everyone on this list is enough to make me
get out.  If he actually contributed something useful, I *might* put 
up with it, but that's not the case.

I'll leave you all to receive your insults from DRS (unforturnately,
I'm sure this activity is the hightlight of his day).

- Eric Bovell
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Stupid stupid remarks

[Jim Balter]

Eric Bovell wrote:
> 
> On 26 Mar 97 at 18:05, DRS wrote:
> 
> > Your lack of civility is amusing. But it proves nothing more than
> > your general status as Unix oaf and Windows wanna-be.
> 
> I originally thought I might get something useful out of this mailing
> list (and maybe even be able to contribute a bit).  Most
> technically-specific mailing lists tend to be civil, intelligent,
> and generally enlightening. But the realization that someone like DRS
> is continuously insulting everyone on this list is enough to make me
> get out.  If he actually contributed something useful, I *might* put
> up with it, but that's not the case.
> 
> I'll leave you all to receive your insults from DRS (unforturnately,
> I'm sure this activity is the hightlight of his day).

Since I feel some responsibility here, I will take it upon myself to
suggest that you not react hastily.  While DRS did get carried away
and posted a number of ad hominem remarks to A Phillip Smith and then
to me, culminating with the quoted silliness, he did this in a small
number of messages in quite a short period; his previous postings
were not of that sort.  In any case, there is plenty of useful
information posted to this mailing list, so I would hope you
wouldn't throw out the baby with the bathwater.  If you don't find the
mailing list of value to you then by all means drop it, but please
don't do just just because someone insulted *me*; I can give as good
as I take, as witnessed by the subject line (which of course was
a play on the previous "... ... question" subject).

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: API's that certainly do work. [was; Re: Windows API calls that don't work? (Was RE: Stupid stupid question :/)

[Colin Peters]

Jim Balter[SMTP:jqb@netcom.com] wrote:
>A. Phillip Smith wrote:
>> I would prefer to think that the other Smith didn't try to link
>> with the -lkernel32 library. In which case, things probably did
>> work for him. If he ever is inclined to repeat the test with that
>> library, I'm sure he'll agree that this is not a figment of our
>> collective imaginations, and we can end this thread.
>
>That may not be enough; if I understood Colin Peters correctly, he tried
>your example under win95 and it worked.  I would love to try it and
>put this (and brain-damaged DRS) to rest, but I don't have gnu-win32
>installed under win95.

In hopes of helping you end all this I'll come in and point out that
the example was compiled under Mingw32. However, that's not why my
attempt worked. Mine worked because the -lkernel32 on the command line
problem is a "known problem" for Mingw32 (listed on the web page). I
simply wasn't aware that it also happened to Cygwin32 users. The fact
that it does pleases me in a perverse way, because it means it's not
just my problem.

To summarize: The GNU-Win32 version of ld appears to have problems if
you link libkernel32 explicitly (e.g. by putting -lkernel32 on the gcc
command line). This may cause the executable to mysteriously fail under
Cygwin32 or produce a GP fault under Mingw32 (the difference is that
Mingw32 doesn't install it's own exception handler). These problems may
appear or disappear depending on whether certain functions (or numbers
of functions?) are linked from the Win32 API (possibly from kernel32?).

To summarize the summary: Don't link with -lkernel32 on your command
line.

Problem not solved, but at least there's a workaround.

Colin.

-- Colin Peters - colin@bird.fu.is.saga-u.ac.jp
-- Saga University Dept. of Information Science
-- http://www.fu.is.saga-u.ac.jp/~colin/index.html
-- http://www.geocities.com/Tokyo/Towers/6162/

-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: API's that certainly do work. [was; Re: Windows API calls that don't work? (Was RE: Stupid stupid question :/)

[A. Phillip Smith]

> 
> DRS wrote:
> 
> -- stuff deleted --

I would prefer to think that the other Smith didn't try to link
with the -lkernel32 library. In which case, things probably did
work for him. If he ever is inclined to repeat the test with that
library, I'm sure he'll agree that this is not a figment of our
collective imaginations, and we can end this thread.

Phil Smith
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".