www.digitalmars.com         C & C++   DMDScript  

c++ - freopen hangs when using -L/ENTRY:_WinMain 16

reply "Wichetael" <wichetael gmx.net> writes:
When using this source:

----
  #include <stdio.h>
  #include <windows.h>

  int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrev, LPSTR szCmdLine, UINT
nSW) {
    FILE* newfp = freopen(TEXT("Testing.log"), TEXT("w"), stdout);
    printf(TEXT("Testing..."));

    return 0;
  }
----

and this command line:  dmc src\test2.cpp -o
test\test2.exe -L/ENTRY:_WinMain 16

The program hangs on executing freopen, when I leave out the -L switch
everything works fine. This seems really strange to me, how can specifying
the entry point (which should be the same as when not using the -L switch)
have such a strange result?

You might ask why I'm using the -L switch, that is because I want to use a
library which implements WinMain and OPTLINK does not look for entry points
in the library files, only in object files. Which in itself seems somewhat
strange to me, Walter, if you would, please have OPTLINK also look for entry
points in library files. I am using version 8.39.5n

Regards, Remko van der Vossen
Feb 20 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Wichetael" <wichetael gmx.net> wrote in message
news:c159hl$2fcn$1 digitaldaemon.com...

 When using this source:

 ----
   #include <stdio.h>
   #include <windows.h>

   int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrev, LPSTR szCmdLine,


UINT

 nSW) {
     FILE* newfp = freopen(TEXT("Testing.log"), TEXT("w"), stdout);
     printf(TEXT("Testing..."));

     return 0;
   }
 ----

 and this command line:  dmc src\test2.cpp -o
 test\test2.exe -L/ENTRY:_WinMain 16

 The program hangs on executing freopen, when I leave out the -L switch
 everything works fine. This seems really strange to me, how can specifying
 the entry point (which should be the same as when not using the -L switch)
 have such a strange result?


That will happen when the startup code gets skipped. You're writing a 16 bit
windows program, you need to specify the right acrtused - see
www.digitalmars.com/ctg/acrtused.html - using a flag to the compiler.


 You might ask why I'm using the -L switch, that is because I want to use a
 library which implements WinMain and OPTLINK does not look for entry


points

 in the library files, only in object files. Which in itself seems somewhat
 strange to me, Walter, if you would, please have OPTLINK also look for


entry

 points in library files. I am using version 8.39.5n

 Regards, Remko van der Vossen


If that's happening, extract the .obj file from the library and link it
explicitly.
Feb 20 2004
parent reply "Wichetael" <wichetael gmx.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:c15h87$30om$2 digitaldaemon.com...

 "Wichetael" <wichetael gmx.net> wrote in message
 news:c159hl$2fcn$1 digitaldaemon.com...

 When using this source:

 ----
   #include <stdio.h>
   #include <windows.h>

   int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrev, LPSTR szCmdLine,


 UINT

 nSW) {
     FILE* newfp = freopen(TEXT("Testing.log"), TEXT("w"), stdout);
     printf(TEXT("Testing..."));

     return 0;
   }
 ----

 and this command line:  dmc src\test2.cpp -o
 test\test2.exe -L/ENTRY:_WinMain 16

 The program hangs on executing freopen, when I leave out the -L switch
 everything works fine. This seems really strange to me, how can




specifying

 the entry point (which should be the same as when not using the -L




switch)

 have such a strange result?


 That will happen when the startup code gets skipped. You're writing a 16


bit

 windows program, you need to specify the right acrtused - see
 www.digitalmars.com/ctg/acrtused.html - using a flag to the compiler.


Actualy it's a win32 program, not win16. The strange thing is that I know
I've used a construction like this before without trouble, so since then
something has changed, unfortunately I don't remember which dmc version I
used at the time. But why should it make any difference if the entry point
is chosen by the compiler or specified by a command line switch...

-mn and -WA do not seem to help, what command line switches should I be
looking for?? obj2asm on test2.obj gets me a extrn __acrtused


 You might ask why I'm using the -L switch, that is because I want to use




a

 library which implements WinMain and OPTLINK does not look for entry


 points

 in the library files, only in object files. Which in itself seems




somewhat

 strange to me, Walter, if you would, please have OPTLINK also look for


 entry

 points in library files. I am using version 8.39.5n

 Regards, Remko van der Vossen


 If that's happening, extract the .obj file from the library and link it
 explicitly.


I'd rather not, and similarly, why should it matter whether the label is in
a library or in an object file

Regadrs, Remko van der Vossen
Feb 21 2004
parent "Walter" <walter digitalmars.com> writes:
"Wichetael" <wichetael gmx.net> wrote in message
news:c18dir$2cmn$1 digitaldaemon.com...

 "Walter" <walter digitalmars.com> wrote in message
 news:c15h87$30om$2 digitaldaemon.com...

 "Wichetael" <wichetael gmx.net> wrote in message
 news:c159hl$2fcn$1 digitaldaemon.com...

 When using this source:

 ----
   #include <stdio.h>
   #include <windows.h>

   int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrev, LPSTR






szCmdLine,

 UINT

 nSW) {
     FILE* newfp = freopen(TEXT("Testing.log"), TEXT("w"), stdout);
     printf(TEXT("Testing..."));

     return 0;
   }
 ----

 and this command line:  dmc src\test2.cpp -o
 test\test2.exe -L/ENTRY:_WinMain 16

 The program hangs on executing freopen, when I leave out the -L switch
 everything works fine. This seems really strange to me, how can




 specifying

 the entry point (which should be the same as when not using the -L




 switch)

 have such a strange result?


 That will happen when the startup code gets skipped. You're writing a 16


 bit

 windows program, you need to specify the right acrtused - see
 www.digitalmars.com/ctg/acrtused.html - using a flag to the compiler.


 Actualy it's a win32 program, not win16.


Ok, but the startup code still needs to get executed.


 The strange thing is that I know
 I've used a construction like this before without trouble, so since then
 something has changed, unfortunately I don't remember which dmc version I
 used at the time. But why should it make any difference if the entry point
 is chosen by the compiler or specified by a command line switch...


The need is getting the right _acrtused symbol defined so the right startup
code gets linked in. Just having the start address right is not sufficient.


 -mn and -WA do not seem to help, what command line switches should I be
 looking for?? obj2asm on test2.obj gets me a extrn __acrtused


 www.digitalmars.com/ctg/acrtused.html should give that info for the various
scenarios.


 I'd rather not, and similarly, why should it matter whether the label is


in

 a library or in an object file


It shouldn't. That would be a bug if it is happening.
Feb 21 2004