www.digitalmars.com         C & C++   DMDScript  

c++.command-line - optlink questions

reply "Daniel Fazekas" <fds mailbox.hu> writes:
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
Dec 18 2002
next sibling parent "Daniel Fazekas" <fds mailbox.hu> writes:
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
Dec 18 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"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
Dec 18 2002
parent reply "Daniel Fazekas" <fds mailbox.hu> writes:
"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
Dec 18 2002
parent "Walter" <walter digitalmars.com> writes:
"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.
Dec 18 2002