I'm posting this in this NG because I cannot see any other where this would have better fit¹.

After reading Altaf's post in c++.dos.32.bits, I remembered that some time ago I was hand holding a friend (by the phone, he lives at some 40 km from me), and after directing him to d/l the dmc package, to check everything was OK, he asked for some sources to compile, after the famous, but not very robust 'hello world' test.

I remember a that occasion not all targets compiled. Eventually my friend and I gave out and now he is doing his work, reviving some old Zortech code for his dissertation work.

So I went back to the ctools sources and found the following in TOOLKIT.MAK:

CFLAGS= -DMSDOS -o+space -I..\include

.c.obj:
	sc -c $(CFLAGS) $*
.
.
.
makedep.com : makedep.obj mem.obj list.obj filespec.obj filesear.obj
	sc -mti makedep.obj mem.obj list.obj filespec.obj filesear.obj \

chmod.com : chmod.c
       sc -mti -I..\include chmod.c

.
.
.
menu.exe : ..\include\menu.h menu.c
	sc -mi -I..\include -DTEST menu


Some interesting questions:

Is the 'i', as used in the mti option, an old memory specifier no longer user in newer versions of the compiler? See, for example, the makedep.com target.

Does the generic rule for objects w/o a memory model specifier presently clash with the target's spec?

What was supposed to be the memory model for 'menu.exe'? The 'i' is not recognized nor listed as a memory model.

I understand these makefiles are 12 to 10 years old, and the ctools package is not 'actively' supported, but I think we can bring these makefiles straight easily!

Regards

-- 
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/

[1] Perhaps if we arrive at a actionable bottom line, we can find other to cross post ;-)

The default memory model is now -mn, which is the win32 memory model. It is no longer -ms. If you need to generate 16 bit executables, you now need to specify a 16 bit memory model.

"Cesar Rabak" <csrabak@uol.com.br> wrote in message news:3C711968.7770AB9B@uol.com.br...
> I'm posting this in this NG because I cannot see any other where this would have better fit¹.
>
> After reading Altaf's post in c++.dos.32.bits, I remembered that some time ago I was hand holding a friend (by the phone, he lives at some 40 km from me), and after directing him to d/l the dmc package, to check everything was OK, he asked for some sources to compile, after the famous, but not very robust 'hello world' test.
>
> I remember a that occasion not all targets compiled. Eventually my friend and I gave out and now he is doing his work, reviving some old Zortech code for his dissertation work.
>
> So I went back to the ctools sources and found the following in TOOLKIT.MAK:
>
> CFLAGS= -DMSDOS -o+space -I..\include
>
> .c.obj:
> sc -c $(CFLAGS) $*
> .
> .
> .
> makedep.com : makedep.obj mem.obj list.obj filespec.obj filesear.obj
> sc -mti makedep.obj mem.obj list.obj filespec.obj filesear.obj \
>
> chmod.com : chmod.c
>        sc -mti -I..\include chmod.c
>
> .
> .
> .
> menu.exe : ..\include\menu.h menu.c
> sc -mi -I..\include -DTEST menu
>
>
> Some interesting questions:
>
> Is the 'i', as used in the mti option, an old memory specifier no longer user in newer versions of the compiler? See, for example, the makedep.com target.
>
> Does the generic rule for objects w/o a memory model specifier presently clash with the target's spec?
>
> What was supposed to be the memory model for 'menu.exe'? The 'i' is not recognized nor listed as a memory model.
>
> I understand these makefiles are 12 to 10 years old, and the ctools package is not 'actively' supported, but I think we can bring these makefiles straight easily!
>
> Regards
>
> --
> Cesar Rabak
> GNU/Linux User 52247.
> Get counted: http://counter.li.org/
>
> [1] Perhaps if we arrive at a actionable bottom line, we can find other to cross post ;-)

Walter wrote:
> 
> The default memory model is now -mn, which is the win32 memory model. It is no longer -ms. If you need to generate 16 bit executables, you now need to specify a 16 bit memory model.
> 

OK. Thanks.

So this bring the first 'correction' or 'update' to present technology would be to have the line

sc -c $(CFLAGS) $*

changed to

sc -c -ms $(CFLAGS) $*

in TOOLKIT.MAK.

Now the mystery remains for the possible original intent of the 'mi' and 'mti' memory models... I surmise that changing 'mti' to 'mt' is OK (it seems clear to me that the original intent is the generation of .COM programs.

So, what would be the correct way of fixing the '-mi' option?

TIA


> "Cesar Rabak" <csrabak@uol.com.br> wrote in message news:3C711968.7770AB9B@uol.com.br...
> > I'm posting this in this NG because I cannot see any other where this would have better fit¹.
> >
> > After reading Altaf's post in c++.dos.32.bits, I remembered that some time ago I was hand holding a friend (by the phone, he lives at some 40 km from me), and after directing him to d/l the dmc package, to check everything was OK, he asked for some sources to compile, after the famous, but not very robust 'hello world' test.
> >
> > I remember a that occasion not all targets compiled. Eventually my friend and I gave out and now he is doing his work, reviving some old Zortech code for his dissertation work.
> >
> > So I went back to the ctools sources and found the following in TOOLKIT.MAK:
> >
> > CFLAGS= -DMSDOS -o+space -I..\include
> >
> > .c.obj:
> > sc -c $(CFLAGS) $*
> > .
> > .
> > .
> > makedep.com : makedep.obj mem.obj list.obj filespec.obj filesear.obj
> > sc -mti makedep.obj mem.obj list.obj filespec.obj filesear.obj \
> >
> > chmod.com : chmod.c
> >        sc -mti -I..\include chmod.c
> >
> > .
> > .
> > .
> > menu.exe : ..\include\menu.h menu.c
> > sc -mi -I..\include -DTEST menu
> >
> >
> > Some interesting questions:
> >
> > Is the 'i', as used in the mti option, an old memory specifier no longer user in newer versions of the compiler? See, for example, the makedep.com target.
> >
> > Does the generic rule for objects w/o a memory model specifier presently clash with the target's spec?
> >
> > What was supposed to be the memory model for 'menu.exe'? The 'i' is not recognized nor listed as a memory model.
> >
> > I understand these makefiles are 12 to 10 years old, and the ctools package is not 'actively' supported, but I think we can bring these makefiles straight easily!
> >
> > Regards
> >
> > --
> > Cesar Rabak
> > GNU/Linux User 52247.
> > Get counted: http://counter.li.org/
> >
> > [1] Perhaps if we arrive at a actionable bottom line, we can find other to cross post ;-)


-- 
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/

I don't know what -mi was for. My suggestion is just remove it. -Walter

"Cesar Rabak" <csrabak@uol.com.br> wrote in message news:3C71B760.78887071@uol.com.br...
> Walter wrote:
> >
> > The default memory model is now -mn, which is the win32 memory model. It
is
> > no longer -ms. If you need to generate 16 bit executables, you now need
to
> > specify a 16 bit memory model.
> >
>
> OK. Thanks.
>
> So this bring the first 'correction' or 'update' to present technology would be to have the line
>
> sc -c $(CFLAGS) $*
>
> changed to
>
> sc -c -ms $(CFLAGS) $*
>
> in TOOLKIT.MAK.
>
> Now the mystery remains for the possible original intent of the 'mi' and 'mti' memory models... I surmise that changing 'mti' to 'mt' is OK (it seems clear to me that the original intent is the generation of .COM programs.
>
> So, what would be the correct way of fixing the '-mi' option?
>
> TIA
>
>
> > "Cesar Rabak" <csrabak@uol.com.br> wrote in message news:3C711968.7770AB9B@uol.com.br...
> > > I'm posting this in this NG because I cannot see any other where this would have better fit¹.
> > >
> > > After reading Altaf's post in c++.dos.32.bits, I remembered that some time ago I was hand holding a friend (by the phone, he lives at some
40
> > > km from me), and after directing him to d/l the dmc package, to check everything was OK, he asked for some sources to compile, after the famous, but not very robust 'hello world' test.
> > >
> > > I remember a that occasion not all targets compiled. Eventually my friend and I gave out and now he is doing his work, reviving some old Zortech code for his dissertation work.
> > >
> > > So I went back to the ctools sources and found the following in TOOLKIT.MAK:
> > >
> > > CFLAGS= -DMSDOS -o+space -I..\include
> > >
> > > .c.obj:
> > > sc -c $(CFLAGS) $*
> > > .
> > > .
> > > .
> > > makedep.com : makedep.obj mem.obj list.obj filespec.obj filesear.obj
> > > sc -mti makedep.obj mem.obj list.obj filespec.obj filesear.obj \
> > >
> > > chmod.com : chmod.c
> > >        sc -mti -I..\include chmod.c
> > >
> > > .
> > > .
> > > .
> > > menu.exe : ..\include\menu.h menu.c
> > > sc -mi -I..\include -DTEST menu
> > >
> > >
> > > Some interesting questions:
> > >
> > > Is the 'i', as used in the mti option, an old memory specifier no
longer
> > > user in newer versions of the compiler? See, for example, the makedep.com target.
> > >
> > > Does the generic rule for objects w/o a memory model specifier
presently
> > > clash with the target's spec?
> > >
> > > What was supposed to be the memory model for 'menu.exe'? The 'i' is
not
> > > recognized nor listed as a memory model.
> > >
> > > I understand these makefiles are 12 to 10 years old, and the ctools package is not 'actively' supported, but I think we can bring these makefiles straight easily!
> > >
> > > Regards
> > >
> > > --
> > > Cesar Rabak
> > > GNU/Linux User 52247.
> > > Get counted: http://counter.li.org/
> > >
> > > [1] Perhaps if we arrive at a actionable bottom line, we can find
other
> > > to cross post ;-)
>
>
> --
> Cesar Rabak
> GNU/Linux User 52247.
> Get counted: http://counter.li.org/