• Japheth (10/10) Mar 24 2006 Hello,
• Walter Bright (3/12) Mar 29 2006 Put the object file with the ordering in it you wish first on the
• Japheth (15/17) Mar 29 2006 Thanks, but I did this already of course, with no success.
• Walter Bright (2/17) Mar 30 2006 Try making _TEXT32 the last member of DGROUP.
• Japheth (9/10) Mar 30 2006 Thanks, but this is no valid option because
• Walter Bright (6/18) Mar 31 2006 This should not be a problem, as all the segments should be marked in
• Japheth (3/8) Mar 31 2006 Thanks anyway!
• Walter Bright (3/4) Mar 31 2006 You can also try just concatenating the 16 and 32 bit sections built in

Japheth <mail japheth.de> writes:

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

Walter Bright <newshound digitalmars.com> writes:

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.

Japheth <mail japheth.de> writes:

 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

Walter Bright <newshound digitalmars.com> writes:

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.

Japheth <mail japheth.de> writes:

 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

Walter Bright <newshound digitalmars.com> writes:

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.

Japheth <mail japheth.de> writes:

 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!

Walter Bright <newshound digitalmars.com> writes:

Japheth wrote:

 Thanks anyway!

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