Execute 16-bit programs under DOS4GW
Bernd Omenitsch
Is there a way to execute 16-bit programs under DOS4GW ?
Thanks,
Bernd Omenitsch
Jim
Odd question.
One answer is 'no, you don't need to'.
If you're looking to get access to extra memory in your 16bit
real-mode program by using DOS4GW, then that's not how it's done. You
need to look at EMS or XMS to do that.
Other than that, you need to move to 32bit protected mode to use the
extra memory, and DOS4GW (or similar) is needed to do that.
If you're a real hacker you could look at flat real mode (aka unreal
mode), which allows you to access more memory in 16 bit mode on
>=386's using the 32 bit registers. Not recommended for the faint
hearted.
Jim
Bernd Omenitsch
I now came up with this, according to your description:
PTR_STRUCT s_path, s_args;
char *path = "12days.exe";
char *args = "";
s_path = alloc_dosmem(strlen(path)+1); // 100h int 0x31
s_args = alloc_dosmem(strlen(args)+1);
memcpy(s_path.protected_address, path, strlen(path)+1);
memcpy(s_args.protected_address, args, strlen(args)+1);
RMI rmi;
rmi.ds = s_path.real_segment;
rmi.edx= 0x0000;
rmi.es = s_args.real_segment;
rmi.ebx= 0x0000;
rmi.eax = 0x4b00;
rmint(0x21, rmi);
printf("EAX: %x \n", rmi.eax);
EAX returns 4b00 and the carry flag == 0
though the program (12days.exe 8k) did not execute.
I implemented alloc_dosmem like this:
PTR_STRUCT alloc_dosmem( unsigned short size )
{
printf("Trying to allocate %d bytes\n", size);
union REGS inreg, outreg;
inreg.w.ax = 0x100;
inreg.w.bx = ( size >> 4 ); // durch 16
int386( 0x31, &inreg, &outreg );
if ( outreg.w.cflag & INTR_CF )
{
error_exit( "Could not allocate DOS memory, error code = %hu\n",
outreg.w.ax );
}
PTR_STRUCT t;
t.real_segment = outreg.w.ax;
t.protected_selector = outreg.w.dx;
t.protected_address = ( char * ) ( ( unsigned ) outreg.w.ax << 4 );
return t;
}
"Michael Devore" <ju...@devoresoftware.com> schrieb im Newsbeitrag
news:bdris6$s1d$1...@www1.scitechsoft.com...
> Both simulate real mode and a direct call should work, although the
pointers
> used will be different since the extender will translate the direct int
21h
> call functions and do a lot of the low memory buffer setup for you then
(or
> should if function 4bh is properly supported by the extender). To remove
> any possibility of a bad parameter or real/pmode 32/16 pointer slip, you
> might want to go with a direct simulate real mode interrupt and bypass
> dealing with the extender translation. Normally that's a bit of overkill,
> but since you're having problems, might be best way to go until you get
> things working. Not that much extra work really.
>
> You'll have to allocate a low DOS memory buffer to hold and pass the
> parameters you copy down, and pass values which point in a real-mode way
to
> the allocated low memory address. DS and ES absolutely have to be real
mode
> values for the passed parameters, not selector values. Remember when you
> copy down to the low memory allocation to use the selector-based pointer
> returned while in the 32-bit program, and to pass the real mode pointer
> returned for the 4bh parameters for real mode. Otherwise grief will
present
> itself.
>
> Unfortunately I'm having to keep this a bit on the theoretical plane since
I
> literally no longer have a machine to test with pure MS-DOS on and haven't
> done real mode calls with an extender in a coupla three years. However,
> back when, it all worked fine after you got the allocation and real mode
> pointers straight. Should work okay for you.
>
> If you keep having problems, I know have examples buried here. From other
> comments here and elsewhere, though, programmers are still doing this sort
> of thing and might be able to give you an actual working code fragment
> better than rooting after my stuff.
>
> "Bernd Omenitsch" <b.ome...@cashpoint.at> wrote in message
> news:bdrfvg$ri0$1...@www1.scitechsoft.com...
> > Michael!
> >
> > Thanks for the good news.
> >
> > Since I've never got 4b00 to work, I was wondering whether you could
point
> > me in the right direction concerning the interrupt call.
> >
> > Do I need to use the simulated real mode interrupt or can I call int 21
> from
> > int386 ?
> >
> > What about the es, ds segment registers? Will I have to allocate the
path
> > and parameter buffers in the low 1 mb area?
> >
> >
> > Thanks very much,
> >
> >
> > Bernd
> >
> >
> > "Michael Devore" <ju...@devoresoftware.com> schrieb im Newsbeitrag
> > news:bdre5s$r6j$1...@www1.scitechsoft.com...
> > > Short answer is yes, it should work with, I'd guess, about any
extender.
> > > Function 4bh certainly should. Make sure you're setting it up
properly
> > for
> > > the extender call.
> > >
> > > Longer answer is if you're having problems, you could well be running
> out
> > of
> > > free DOS memory. DOS memory can be reserved via various mechanisms
> > > depending on extender. There is even a way, or two, or three, to swap
> > > memory images to disk to free up more DOS memory, although hmmm, I
don't
> > > recall how well they work in 32-bit flat mode. Think they do.
Pretty
> > sure
> > > at least one does.
> > >
> > > If you can't get a more definite answer, try a single line 32-bit
main()
> > > which exec's the 16-bit program. That should always work and avoid
> > > potential memory problems that could occur with bigger non-toy
programs.
> > If
> > > you have problems in a one-liner, you've got a setup problem somewhere
> or
> > > else you have really small free DOS memory to begin with. Like well
> under
> > > than 400K. You may get extenders to work down as low as ~200K free
DOS
> > > memory with additional XMS, but not a good bet crunched down there.
> > >
> > > Final caveat for now is that mixing protected-mode 32-bit and
> > protected-mode
> > > 16-bit doesn't always work depending on drivers, extenders, etc. I'm
> > > assuming here that you want to exec a real mode 16-bit program.
> > >
> > > "Bernd Omenitsch" <b.ome...@cashpoint.at> wrote in message
> > > news:bdrbmu$qqj$1...@www1.scitechsoft.com...
> > > > Jim!
> > > > Seems like a small misunderstanding.
> > > > I meant that I'm already using DOS4GW (Pmode/w, Causeway etc..), and
> my
> > > > question was, whether it is possible to execute a 16-bit application
> > from
> > > a
> > > > 32-bit application running under DOS 6.22.
> > > >
> > > > Actually I don't really care which Dos extender, I'm just wondering
if
> > > there
> > > > is one that supports it (and how), because whichever it is, that's
the
> > one
> > > > I'm gonna be using.
> > > >
> > > > Because neither system() nor spawn..() seem to work.
> > > > And I also couldn't get int 21, 0x4b00 to work.
> > > >
> > >
> > >
> >
> >
>
>
Michael Devore
Michael Devore
Bernd Omenitsch
Seems like a small misunderstanding.
I meant that I'm already using DOS4GW (Pmode/w, Causeway etc..), and my
question was, whether it is possible to execute a 16-bit application from a
32-bit application running under DOS 6.22.
Actually I don't really care which Dos extender, I'm just wondering if there
is one that supports it (and how), because whichever it is, that's the one
I'm gonna be using.
Because neither system() nor spawn..() seem to work.
And I also couldn't get int 21, 0x4b00 to work.
Thank You,
Bernd
"Jim" <so...@not.com> schrieb im Newsbeitrag
news:44t1gv8vn8jur62mm...@4ax.com...
Bernd Omenitsch
the line
rmint(0x21, rmi);
is supposed to be
rmi = rmint(0x21, rmi);
now returning EAX == 8
meaning "not enough memory"
at least thats a documented error message, but how do I get it to have
enough memory ?
I boot into a clean environment (F5)
Bernd
"Bernd Omenitsch" <b.ome...@cashpoint.at> schrieb im Newsbeitrag
news:bdrlsq$sk7$1...@www1.scitechsoft.com...
> Sorry, I meant Michael!
>
> "Bernd Omenitsch" <b.ome...@cashpoint.at> schrieb im Newsbeitrag
> news:bdrlrt$sk3$1...@www1.scitechsoft.com...
Bernd Omenitsch
Thanks for the good news.
Since I've never got 4b00 to work, I was wondering whether you could point
me in the right direction concerning the interrupt call.
Do I need to use the simulated real mode interrupt or can I call int 21 from
int386 ?
What about the es, ds segment registers? Will I have to allocate the path
and parameter buffers in the low 1 mb area?
Thanks very much,
Bernd
"Michael Devore" <ju...@devoresoftware.com> schrieb im Newsbeitrag
news:bdre5s$r6j$1...@www1.scitechsoft.com...
Bernd Omenitsch
"Bernd Omenitsch" <b.ome...@cashpoint.at> schrieb im Newsbeitrag
news:bdrlrt$sk3$1...@www1.scitechsoft.com...
Bernd Omenitsch
typedef struct
{
WORD env_segment;
WORD cmd_offset;
DWORD cmd_segment;
DWORD fcb1;
DWORD fcb2;
} pb;
union REGS inregs, outregs;
struct SREGS sregs;
PTR_STRUCT s_path;
PTR_STRUCT s_args;
PTR_STRUCT s_pb;
char *path = "12days.exe";
char *args = "\0\r";
s_path = alloc_dosmem(strlen(path)+1);
s_args = alloc_dosmem(strlen(args)+1);
s_pb = alloc_dosmem(sizeof(pb));
pb pblock;
pblock.env_segment = 0;
pblock.cmd_segment = (int)s_args.real_segment;
pblock.cmd_offset = 0;
pblock.fcb1 = NULL;
pblock.fcb2 = NULL;
memcpy((void*)s_pb.protected_address, &pblock, sizeof(pb));
memcpy((void*)s_path.protected_address, path, strlen(path)+1);
memcpy((void*)s_args.protected_address, args, strlen(args)+1);
RMI rmi;
rmi.ds = s_path.real_segment;
rmi.edx= 0x0000;
rmi.es = s_pb.real_segment;
rmi.ebx= 0x0000;
rmi.eax = 0x4b00;
rmi = rmint(0x21, rmi);
printf("EAX: %x\n", rmi.eax);
"Michael Devore" <ju...@devoresoftware.com> schrieb im Newsbeitrag
news:bdris6$s1d$1...@www1.scitechsoft.com...