hello,

I just cannot figure out how to do a couple of things with the linker.
I'm only interested in Win32, and I have both tried invoking the linker via
DMC/SC and directly, with no difference.

Is there any way to stop the linker from outputting a .map file? According
to the documentation, it shouldn't even generate it in the first place,
unless you specify /MAP. I've also tried the /NOMAP switch, to no effect. A
short .map file still gets generated, no matter what.
I wouldn't mind it if I could at least set the target directory of the map
file so it wouldn't end up in the current directory. I couldn't find a way
to do that either.

Is there any way to set the subsystem version outputted in the PE headers _without_ using a .def file? Like you can do it in the .def file writing "SUBSYSTEM WINDOWS,4.0", and you may also specify the subsystem on the command line via "/SUBSYSTEM:WINDOWS". Other linkers similarly allow you to add the version number there, like "/SUBSYSTEM:WINDOWS,4.0". This doesn't seem to work with optlink.

Is there a way to tell the linker not to generate the .reloc section? This is just unnecessarily making the executables larger, they're unnecessary for Win32 application executables.

What makes the optlink generated executables incompatible with the Win32
executable packers? UPX (http://upx.sourceforge.net/) for example says:
upx: something.exe: CantPackException: file is possibly packed/protected
(try --force)
If I try --force, the file gets packed, but it won't work any more
EXEs created with the Borland, Microsoft, Metrowerks, Watcom, MinGW-GCC or
LCC linkers may be packed without problems.

Is there a linker option to set the checksum field in the PE header? ("The operating system requires the Checksum for device drivers. Set the Checksum for release versions of your device drivers to ensure compatibility with future operating systems.") There is a switch named "/CHECKSUM" which according to the documentiation doesn't do anything, while it seems to do something, as it makes the linker output a handful or warning messages.

Is there an option for setting the operating system version field in the PE header? OPTLINK sets this to 1.00 while just about any other linker uses 4.00. The documentation mentions that you can specify a version number after the EXETYPE directive, but that only works for the windows (Win3.x) type, not NT (win32).

Thanks a lot,
Daniel

I'll answer one of my own questions, as I just figured it out. :-)

> Is there a way to tell the linker not to generate the .reloc section? This is just unnecessarily making the executables larger, they're unnecessary
for
> Win32 application executables.

There is, just use the /FIXED linker switch.

Still no luck with the others though.

--
Daniel

"Daniel Fazekas" <fds@mailbox.hu> wrote in message news:atq37f$2m01$1@digitaldaemon.com...
> Is there any way to stop the linker from outputting a .map file? According to the documentation, it shouldn't even generate it in the first place, unless you specify /MAP. I've also tried the /NOMAP switch, to no effect.
A
> short .map file still gets generated, no matter what.
> I wouldn't mind it if I could at least set the target directory of the map
> file so it wouldn't end up in the current directory. I couldn't find a way
> to do that either.

sc -c hello.c
link hello;

will not create a .map file.

> Is there any way to set the subsystem version outputted in the PE headers _without_ using a .def file? Like you can do it in the .def file writing "SUBSYSTEM WINDOWS,4.0", and you may also specify the subsystem on the command line via "/SUBSYSTEM:WINDOWS". Other linkers similarly allow you
to
> add the version number there, like "/SUBSYSTEM:WINDOWS,4.0". This doesn't seem to work with optlink.

I'm afraid you'll need to use a .map file for that.


> Is there a way to tell the linker not to generate the .reloc section? This is just unnecessarily making the executables larger, they're unnecessary
for
> Win32 application executables.

Sorry.

> What makes the optlink generated executables incompatible with the Win32
> executable packers? UPX (http://upx.sourceforge.net/) for example says:
> upx: something.exe: CantPackException: file is possibly packed/protected
> (try --force)
> If I try --force, the file gets packed, but it won't work any more
> EXEs created with the Borland, Microsoft, Metrowerks, Watcom, MinGW-GCC or
> LCC linkers may be packed without problems.

I don't know what the bug in UPX is.

> Is there a linker option to set the checksum field in the PE header? ("The operating system requires the Checksum for device drivers. Set the
Checksum
> for release versions of your device drivers to ensure compatibility with future operating systems.") There is a switch named "/CHECKSUM" which according to the documentiation doesn't do anything, while it seems to do something, as it makes the linker output a handful or warning messages.

The /checksum causes it to read the checksum value from .obj file records, which is not output by the compiler (hence the warnings). There currently isn't a way to set the PE checksum.

> Is there an option for setting the operating system version field in the
PE
> header? OPTLINK sets this to 1.00 while just about any other linker uses 4.00. The documentation mentions that you can specify a version number
after
> the EXETYPE directive, but that only works for the windows (Win3.x) type,
> not NT (win32).

Sorry, there isn't. Maybe that's why UPX won't work?

In any case, your suggestions for improvements to optlink are great and I'll add them to the list. -Walter

"Walter" <walter@digitalmars.com> wrote in message news:atq94i$2qqg$1@digitaldaemon.com...
> > Is there any way to stop the linker from outputting a .map file?
According
> sc -c hello.c
> link hello;
> will not create a .map file.

True, but unfortunately only true as long as you are not specifying any
additional import libraries.
Try this:

link hello,,,user32+kernel32;

(instead of simply link hello)

...and there's the .map file.
Specifying additional import libraries is pretty much unavoidable for a
larger Windows application.

> > Is there a way to tell the linker not to generate the .reloc section?
This
> Sorry.

Actually there is, as I've discovered since then. :) The /FIXED option, same as in the Microsoft linker, only in Microsoft's linker it is on by default.

> > What makes the optlink generated executables incompatible with the Win32
> > executable packers? UPX (http://upx.sourceforge.net/) for example says:
> > upx: something.exe: CantPackException: file is possibly packed/protected
> > (try --force)
> > If I try --force, the file gets packed, but it won't work any more
> > EXEs created with the Borland, Microsoft, Metrowerks, Watcom, MinGW-GCC
or
> > LCC linkers may be packed without problems.
> I don't know what the bug in UPX is.

There has to be something weird in the way optlink generates Win32
executables, if out of the eight different Win32 C compiler packages - and
their appropriate linkers - I've tested only the ones generated by optlink
don't work.
I'll try to research it some more, maybe I will be able to pinpoint the
exact cause.

> > Is there an option for setting the operating system version field in the
PE
> > header? OPTLINK sets this to 1.00 while just about any other linker uses 4.00.
> Sorry, there isn't. Maybe that's why UPX won't work?

No, I've tried changing that by hand. Also LCC-win32's linker puts 1.00 there too, without affecting compressabilty.

This one was more of simple curiosity, as I don't think the value of this
field changes anything at all. I've just read today about someone wanting to
change it with another linker, which also doesn't allow changing it, so I
made some tests to see which linkers let you alter its value.
Only four out of the eight I tested. I wanted to make sure I'm correct on
into which half Digital Mars' optlink belongs to. :)

> In any case, your suggestions for improvements to optlink are great and
I'll
> add them to the list. -Walter

Thank you very much for your prompt reply, much appreciated!

--
Daniel

"Daniel Fazekas" <fds@mailbox.hu> wrote in message news:atqbr8$2snv$1@digitaldaemon.com...
> Try this:
> link hello,,,user32+kernel32;
> (instead of simply link hello)
> ...and there's the .map file.

You're right. What's happening is the map file name goes between the ,, and it being blank means 'use the default name' like for the .exe file.

> > > Is there a way to tell the linker not to generate the .reloc section?
> Actually there is, as I've discovered since then. :) The /FIXED option,
same
> as in the Microsoft linker, only in Microsoft's linker it is on by
default.

Ok!

> > > What makes the optlink generated executables incompatible with the
Win32
> > > executable packers? UPX (http://upx.sourceforge.net/) for example
says:
> > > upx: something.exe: CantPackException: file is possibly
packed/protected
> > > (try --force)
> > > If I try --force, the file gets packed, but it won't work any more
> > > EXEs created with the Borland, Microsoft, Metrowerks, Watcom,
MinGW-GCC
> or
> > > LCC linkers may be packed without problems.
> > I don't know what the bug in UPX is.
> There has to be something weird in the way optlink generates Win32
> executables, if out of the eight different Win32 C compiler packages - and
> their appropriate linkers - I've tested only the ones generated by optlink
> don't work.
> I'll try to research it some more, maybe I will be able to pinpoint the
> exact cause.

Optlink generated executables work fine on every win32 loader I know of, from win32s to XP, and even some 3rd party win32 dos extenders. I'd be curious if you find out what the cause is.


> > > Is there an option for setting the operating system version field in
the
> PE
> > > header? OPTLINK sets this to 1.00 while just about any other linker
uses
> > > 4.00.
> > Sorry, there isn't. Maybe that's why UPX won't work?
>
> No, I've tried changing that by hand. Also LCC-win32's linker puts 1.00 there too, without affecting compressabilty.

The 1.00 is there to support versions of win32 prior to NT 4.0. I don't know if earlier loaders checked the version or not.