DOS ain't dead

AFAIK C should place all global variables into one segment one by one so you only need to get pointer to the first variable and data segment. But there may be some problem with aligning where some dummy bytes are placed between Byte variables - e.g.
int a; - 0x1100
Byte b; - 0x1102
int c; - 0x1104 (instead of 0x1103)

Aligning may be turned off by some compiler option but you are not sure if another compiler can disable it. May be better use some kind of attribute packed and put all vars into a packed structue. Then you will be safe that any extra bytes was added.

---
DOS gives me freedom to unlimited HW access.

> I am trying to re-writing my program Explorer PC (graphical file manager
> for DOS).Before it was written in Turbo Assembler but now I am using Turbo
> C++.
> My problem is that need making to ensure to me that several variables
> remain together in the executable file (.exe) or when running are located
> together in the same segment.
> For example:
> int a; SEG=0 OFFSET=0
> int b; SEG=0 OFFSET=2
> int c; SEG=0 OFFSET=4
> In assembler I can control this but in C++ is possible?

Something that I have seen in FreeBSD headers was something like this:

struct {
int ___prefix_a;
int ___prefix_b;
int ___prefix_c;
#define a __prefix_a
#define b __prefix_b
#define c __prefix_c
} a;

IOW make a record with dummy names, and then use #defines to access them.

Costs a bit of error message clarity though (and C/C++ doesn't have that much of that already)

> My problem is that need making to ensure to me that several variables
> remain together in the executable file (.exe) or when running are located
> together in the same segment.
> For example:
> int a; SEG=0 OFFSET=0
> int b; SEG=0 OFFSET=2
> int c; SEG=0 OFFSET=4
> In assembler I can control this but in C++ is possible?
> Thanks
In addition to using struct/TC alternatives which have already been covered. There are at least 2 other alternatives using TC that sprung to mind:

1) Don't hard-code in your resources (e.g. like you did with the ASM version) and instead use malloc - this has the advantage your resources can easily be changed by others particularly if you pack them in as a common data format, e.g. On an unreleased DOS game I wrote all the code to use the Windows .FNT/.FON file format and various graphics formats. There are however now a lot of free graphics libraries out there that you could easily incorporate. Certainly storing resources such as text non-hardcoded always helps translators.

2) Use BGIOBJ as it is known as with Turbo C (or BINOBJ as it has also been known, e.g. with Turbo Pascal). For example:

bgiobj mydata.bin mydata.obj mydata

Once a file has been converted with BGIOBJ/BINOBJ you can then include the .OBJ file at link time and use as data or code (with caution!) as appropriate.

Note: Some versions (e.g. TC3 version) support a /F parameter:
"/F selects 'far' version (please read the documentation before using /F)."

Amusingly as I just discovered if you look up BGIOBJ in a physical Turbo C manual, it just refers to UTIL.DOC which can normally be found in C:\TC\DOC - having just re-referenced it for you I was reminded that it only talks about BGI files which we don't care about (certainly I never have). However don't be fooled you can use the utility for other purposes. Anyway, I have just noted UTIL.DOC basically explains that /F instructs BGIOBJ to use a different segment name other than _TEXT in the form of filename_TEXT - the UTIL.DOC documentation takes up a lot of space to explain this though :)


Some Borland compiler examples
Ok, firstly lets imagine we have a text file called HW.TXT which you've guessed it contains:

Hello World!

as above we use bgiobj or binobj to convert it (the parameters are the same):

bgiobj hw.txt hw hw
or
binobj hw.txt hw hw

The above will result in hw.obj - below are some examples of Borland linking:


Borland/Turbo C linking examples
With Borland C products linking an obj file in is very straight forward, e.g:

\tc\bin\bcc myproject.c hw.obj
or
\tc\bin\tcc myproject.c hw.obj

Note: Borland store BGIOBJ by default under C:\TC\BGI directory not C:\TC\BIN


Turbo Pascal example 1/2
Linking in OBJ data at compile with Turbo Pascal is however a bit more complex but can still be done. Firstly here is a basic example of how to fool TP's linker into letting us get away with including non-code object data:
{$F+}  {force far calls}

{$L hw.obj}

procedure hw; external;  {fool TP as $L is supposed to be for code only}

Begin
  Halt; {Halt as we do NOT want to run the following reference which is DATA}
  HW;   {We need to include a reference to it otherwise TP won't include it}
End.

Turbo Pascal example 2
In this example we print out the text that was linked into our EXE from HW.OBJ after fooling TP's linker as already shown above. Note: this time however we use a move to overcome Borland's checking for "invalid variables".

{$F+}  {force far calls}

{$L hw.obj}

procedure hw; external;  {fool TP as $L is supposed to be for code only}

Var
  MyMessage:array[1..12] of char; {Our example text is 12 bytes long}

Begin
  Writeln;
  Move(Mem[Seg(HW):Ofs(HW)], MyMessage, SizeOf(MyMessage)); {What invalid variable? :}
  Writeln('My Message = ', MyMessage);
  Halt; {Halt as we do NOT want to run the following reference which is DATA}
  HW;   {We need to include a reference otherwise TP won't include it}
End.


Note: There are many ways of doing things like the above to add data/code during (or after) linking with Borland's products. e.g. After linking you can use Ben Castricum's UNP (e.g. unp412.zip) has the "m" (MarkEXE) option to "insert a file into an EXE's header" which is another basic way of getting resources into EXE files.