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

"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.

"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

"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.