DOS/16bit/medium/huge model: Is it possible to force functions or data to segments?

[LowLevelMahn]

im working on a reverse engineering project of a medium and a huge model exe and want to prepare a test-project for playing around with code/segment ordering before going on the big project - so something that contains multiple segments for code[data]

so for example: i hope to get a simple medium(huge) model dos exe that contains multiple code segments with a single function each
and/or multiple data segments - that mean multiple segments in the relocation table for code+data

`
[func1.c]
int far func1(){ return 0; }

[func2.c]
int far func2(){ return 1; }

[func3.c]
int far func3(){ return 2; }

[main.c]
int func1();
int func2();
int func3();
int main()
{
return func1()+func2()+func3();
}
`

is that even possible with Watcom C or will the compiler "optimize" combine/merge segment freely on its own?

so something like:

put func1 in segmentX
put func2 in segmentY
put variable ABC in segmentZ

[jmalak]

I am not sure if I understand correctly what you need.
First we should clear memory models. OW know following 16-bit memory models small/medium/compact/large/huge.
It is compiler memory models. This represent two category for functions and data, near or far.
What is near is put into single default segment _TEXT (code) and _DATA (data). The _DATA segment is part of DGROUP which is always near (data).
Any item which is far is put into separate far segment by <module name>_TEXT (code) and <module_name>_DATA (data).
Linker do optimization for some type of segments that put them together. See segment ordering rules for linker.
if you need some specific position of segment you can use linker directives for order segments or you can use some special names for segments and define it by compiler -n... options.
other posibility is to use #pragma for naming segments etc.
But take into account that best is to use standard segment ordering otherwise you can broke some linker rules for segments and result can be different from what you expected.

Anyway any far item can be anywhere because access is by far pointer, therefore segment is not important.
For near items which is put into single segment is not problem with order of segments too.

[LowLevelMahn]

I am not sure if I understand correctly what you need. First we should clear memory models.
OW know following 16-bit memory models small/medium/compact/large/huge. It is compiler memory models.
This represent two category for functions and data, near or far.

that is 100% clear - usually im only working with tiny(single seg, near/near) or small model(one data, one code segment, near,near)
i know what far/near functions/ptr do/behave, how they work - wrote a small emulator myself - i also know why huge-ptr can be very slow advancing them (due to offset-overflow handling)

What is near is put into single default segment _TEXT (code) and _DATA (data). The _DATA segment is part of DGROUP which is
always near (data). Any item which is far is put into separate far segment by <module name>_TEXT (code) and
<module_name>_DATA (data). Linker do optimization for some type of segments that put them together. See segment ordering rules
for linker. if you need some specific position of segment you can use linker directives for order segments or you can use some special
names for segments and define it by compiler -n... options. other posibility is to use #pragma for naming segments etc. But take into
account that best is to use standard segment ordering otherwise you can broke some linker rules for segments and result can be
different from what you expected.

i tell you the complete story maybe you can then better see my needs - maybe i only need WLink to solve that

1. i've got a medium model Microsoft C 5.1 exe with one data-segment and multiple code-segments
2. i diassembled the exe into re-assemble-able assembler-code that creates the 100% identical exe
3. i partially rewrite single asm functions to its original C style, compiled with the same MSC 5.1 to be binary equal to the assembler code
4. now i try to link that stuff together to replace the diassembled assember-function with the equivalent C function at the very same position to keep the resulting binary 100% equal to the original

this 100% equal binary thing is to prevent translation errors that happen very easily while reversing - resulting in a nearly 100% recovery of the original code (without correct symbol names etc. but definitily code-identical) simliar projects: https://github.com/lethal-guitar/Duke2Reconstructed, https://github.com/smitelli/cosmore, https://github.com/asiekierka/reconstruction-of-zzt
and the replacing happens step by step, not all in one shot because its just too much code - so the rewritten code grows over time and testing

i have no real idea how the part 4 can be reached

my idea was to generate some sort of example with multiple segments in Watcom C (because of the good documentation etc.)
and try the strategie on a smaller example

[jmalak]

Thanks for more explanation, I think now I understand better.
If you know that original source code was Microsoft C 5.1 than it uses same memory model as WATCOM.
I don't think that segment order is important.
But if you want to order segments then for same type of segments it is ordered by order of object files on wlink command line.
It means all near segments code/data are add in command line order, far segments are add also in command line order.
If it is Microsoft C 5.1 application without any TSR code then I don't expect anything specific that order is not critical.
But if you want hardcode segments order then you can specify it in first simple assembly module where you specify all segments order then command line order can be any except this special module must be first on command line to define segments order for rest of command line. I think WATCOM linker can use alphabetics ordering of segments then you can name segments in appropriate order.

Below is references to OW documentation which should help you with selection of suitable method, it is not single way.

OW Linker DOS memory layout - DOSSEG directive
OW Linker ORDER directive - explicit ordering
OW Compilers options for naming segments
-nc
-nd
-nm
-nt

Anyway it is necessary to know name and class for each segment or design it.
It determine how OW linker will order and combine segments. OW linker uses all segment attributes for ordering and combine segments.
Good is to use one class for code and one class for data. It can simplify linking because linker combine segments by class and by segment name and attributes and by order of compiled modules.
OW use default class 'CODE' for code segments and class 'DATA' for data.

[LowLevelMahn]

thank you for the info - i think that is enough for my testing