Thread overview
optlink segment ordering problem
Mar 25, 2006
Japheth
Mar 29, 2006
Walter Bright
Mar 30, 2006
Japheth
Mar 30, 2006
Walter Bright
Mar 31, 2006
Japheth
Mar 31, 2006
Walter Bright
Mar 31, 2006
Japheth
Mar 31, 2006
Walter Bright
March 25, 2006
Hello,

I have a binary which needs a special segment ordering:

_TEXT    16bit DGROUP
_DATA    16bit DGROUP
_TEXT32  32bit

Although I used linker option /NOREO the _TEXT32 segment is always grouped *before* DGROUP. How could this be avoided? (there is no module with the "DOSSEG" directive included).

Regards

Japheth
March 29, 2006
Japheth wrote:

> I have a binary which needs a special segment ordering:
> 
> _TEXT    16bit DGROUP
> _DATA    16bit DGROUP
> _TEXT32  32bit
> 
> Although I used linker option /NOREO the _TEXT32 segment is always grouped *before* DGROUP. How could this be avoided? (there is no module with the "DOSSEG" directive included).

Put the object file with the ordering in it you wish first on the command line to the linker.
March 30, 2006
> Put the object file with the ordering in it you wish first on the command line to the linker.

Thanks, but I did this already of course, with no success.

The first module is written in assembly:

_DATA   segment dword use16 public 'CODE'
_DATA	ends
_TEXT	segment byte use16 public 'CODE'
_TEXT	ends
_TEXT32	segment dword use32 public 'CODE'
_TEXT32	ends

DGROUP  group _DATA, _TEXT
CGROUP32 group _TEXT32

So I really would expect _TEXT32 to be "behind" DGROUP, but OPTLINK puts it before DGROUP. Using MS OMF linker and tlink _TEXT32 is behind DGROUP, but they have some problems with 32bit object modules.

Regards

Japheth
March 30, 2006
Japheth wrote:

> The first module is written in assembly:
> 
> _DATA   segment dword use16 public 'CODE'
> _DATA    ends
> _TEXT    segment byte use16 public 'CODE'
> _TEXT    ends
> _TEXT32    segment dword use32 public 'CODE'
> _TEXT32    ends
> 
> DGROUP  group _DATA, _TEXT
> CGROUP32 group _TEXT32
> 
> So I really would expect _TEXT32 to be "behind" DGROUP, but OPTLINK puts it before DGROUP. Using MS OMF linker and tlink _TEXT32 is behind DGROUP, but they have some problems with 32bit object modules.

Try making _TEXT32 the last member of DGROUP.
March 31, 2006
> Try making _TEXT32 the last member of DGROUP.

Thanks, but this is no valid option because

- the 32bit segment must not be in DGROUP, because it is moved to extended memory once it has been loaded by the DOS loader. That's the reason why I want it to be the last segment in the binary.

- the assembler (MASM) complains about changing segment attributes. It has the strong opinion that one cannot mix 16bit and 32bit segments in a group.

Is the /NOREO option not functional/not implemented?

Regards

Japheth

March 31, 2006
Japheth wrote:
> 
>> Try making _TEXT32 the last member of DGROUP.
> 
> Thanks, but this is no valid option because
> 
> - the 32bit segment must not be in DGROUP, because it is moved to extended memory once it has been loaded by the DOS loader. That's the reason why I want it to be the last segment in the binary.

Why not just use the supported 32 bit DOS extender?

> - the assembler (MASM) complains about changing segment attributes. It has the strong opinion that one cannot mix 16bit and 32bit segments in a group.

This should not be a problem, as all the segments should be marked in the assembler source as 32 bits.

> Is the /NOREO option not functional/not implemented?

I don't know. I didn't write the linker. I'm loathe to change how it works, though, because it may break a lot of existing code.
March 31, 2006
> Why not just use the supported 32 bit DOS extender?

Well, the binary *is* a dpmi host, so it cannot use another DOS extender's host.

> This should not be a problem, as all the segments should be marked in the assembler source as 32 bits.

but the example 4 lines above show that _DATA and _TEXT are (and must be) 16bit.

> I don't know. I didn't write the linker. I'm loathe to change how it works, though, because it may break a lot of existing code.

Thanks anyway!


March 31, 2006
Japheth wrote:

> Thanks anyway!

You can also try just concatenating the 16 and 32 bit sections built in  separate files.