Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

64-bit DOS extender?

597 views
Skip to first unread message

Wiktor S.

unread,
Sep 28, 2004, 1:35:43 PM9/28/04
to
I just wonder, would it be possible to create something similar to emm386
and a 64-bit DOS extender for AMD64 processors?

--
Azarien

wswiktor<attomaaku>poczta<dotto>fm

TS

unread,
Sep 28, 2004, 4:11:22 PM9/28/04
to
>I just wonder, would it be possible to create something similar to emm386
>and a 64-bit DOS extender for AMD64 processors?

Something like DPMI or DOS4GW would be rather trivial, but a real mode
emulation would be way more complicated since there is no v86 mode
available when long mode is active.

Wiktor S.

unread,
Sep 28, 2004, 6:44:10 PM9/28/04
to
>> I just wonder, would it be possible to create something
>> similar to emm386 emm386 and a 64-bit DOS extender for

>> AMD64 processors?
>
> Something like DPMI or DOS4GW would be rather trivial,

I think it shouldn't much differ from existing 32-bit extenders -- just
different mode switching routine?

> but a real mode emulation would be way more complicated since
> there is no v86 mode available when long mode is active.

Is there something wrong with so called "compatibility mode", to run
16/32-bit software on 64-bit systems? Why it would "way more complicate"
things?

KVP

unread,
Sep 29, 2004, 2:20:23 AM9/29/04
to
"Wiktor S." <spam...@crayne.org> wrote:
> >> I just wonder, would it be possible to create something
> >> similar to emm386 emm386 and a 64-bit DOS extender for
> >> AMD64 processors?
> > Something like DPMI or DOS4GW would be rather trivial,
> I think it shouldn't much differ from existing 32-bit extenders -- just
> different mode switching routine?

Yes, a switch from 16 bit real mode to 16 or 32 bit protected mode,
then a switch to long mode, then to 64 bit long mode.

> > but a real mode emulation would be way more complicated since
> > there is no v86 mode available when long mode is active.
> Is there something wrong with so called "compatibility mode", to run
> 16/32-bit software on 64-bit systems? Why it would "way more complicate"
> things?

The long mode supports only 16 and 32 bit _protected_ mode. There is no
support for real mode or v86 mode. Every extender willing to use the bios
or other real mode software have to either return to real mode or switch
back to 32 bit legacy mode, and use v86 mode from there. Either way, a
simple bios call requires at least four mode switches and two separate
paging systems switched on every mode switch, just to work.

Viktor

Wiktor S.

unread,
Sep 29, 2004, 2:48:19 PM9/29/04
to
> The long mode supports only 16 and 32 bit _protected_ mode. There is
> no support for real mode or v86 mode. Every extender willing to use
> the bios or other real mode software have to either return to real
> mode or switch back to 32 bit legacy mode, and use v86 mode from
> there. Either way, a simple bios call requires at least four mode
> switches and two separate paging systems switched on every mode
> switch, just to work.


I presume 64-bit Windows cannot run DOS programs at all?

--
Azarien

valy

unread,
Oct 1, 2004, 1:33:50 PM10/1/04
to
Hi

I have recently installed Win XP 64-bit beta, 2nd partition after
Win98, on my Opteron.
It works quite fine actually, it is a good surprise.
The only trouble is the "DOS box" (it is an emulation, remember) is
incredibly slow (several seconds on any print).

DOS programs won't execute.
I have made a program : DOS->PM16->PM32->64-bit long mode with
GDT/IDT->PM32->PM16->DOS.
My intention : a tiny OS on an USB key (my Opteron can boot onto it).
Minimal GUI for the moment (I aim Turbo C's IDE). Full ring0.
Multitask since I aim at making it "an OS for true 64-bit optimized
programs". Not a substitute to Windows : I am glad with 98. Rather an
OS with no security/resource eater/windows limitations... sthg for
which I am free to make what I want. Especially, testing 64-bit mode
and the PMC as freely as I can (maybe to write a compiler, let us
dream...)

Anybody interested ? Somebody experienced ? For the GUI I need 16-bit
or 32-bit asm or C sources to begin with, so any help is appreciated.
This is a lot of work... I've never written a debugger... many
difficulties...

Wiktor S.

unread,
Oct 1, 2004, 4:10:26 PM10/1/04
to
> I have recently installed Win XP 64-bit beta, 2nd partition after
> Win98, on my Opteron.

I don't (hopefully yet) have an AMD64 processor, only Bochs emulator on
which 64-bit Windows XP crashes on install :-( Bug reported.

> It works quite fine actually, it is a good surprise.
> The only trouble is the "DOS box" (it is an emulation, remember) is
> incredibly slow (several seconds on any print).
> DOS programs won't execute.

So they are incredibly slow or don't execute?

Or you mean that programs for DOS don't work at all (what's the message?),
while Win32/Win64 console programs are so slow? That's something Microsoft
really has to fix...

> I have made a program : DOS->PM16->PM32->64-bit long mode with
> GDT/IDT->PM32->PM16->DOS.

I'm going to write it too, but as for now I'm still reading that huge AMD
documentation - my program now works like:

if amd64detected
then "Initializing...", hang
else "no AMD64", exit

:-)

This will be my first attempt to write an OS or OS-like code, and I decided
to start from 64-bits (even emulated) as it's going to be the future
according to current signs on earth and heaven.

> Anybody interested ?

If it works on Bochs... ;-)

> Somebody experienced ?

not me...

> For the GUI I need 16-bit or 32-bit asm or C sources
> to begin with, so any help is appreciated.

Are you going to directly access the hardware from the beginning, or start
with calling DOS/BIOS interrupts?

> This is a lot of work...

Oh, indeed..

--
a_rien

e-mail: wswiktor&poczta,fm

valy

unread,
Oct 4, 2004, 2:02:36 PM10/4/04
to
> Or you mean that programs for DOS don't work at all (what's the message?),
> while Win32/Win64 console programs are so slow? That's something Microsoft
> really has to fix...
>
You're right : DOS programs won't work. Win32/64 console programs are
extremely slow. My video board is a standard SVGA/PCI that works very
well with Win9x (800x600, 24-bit).

>
> If it works on Bochs... ;-)
>

Nope. Sorry, I tried Bochs, this is great for 32-bit but it hangs as
soon as I use CR4. It was 4 or 6 months ago. Paging is not an option
with AMD64 long mode.

> Are you going to directly access the hardware from the beginning, or start
> with calling DOS/BIOS interrupts?
>

I want no BIOS calls if possible : too much slow, going back to
16-bit... The trouble is I know hardly nothing about
mouse/hdd/keyboard w/o BIOS calls...

AMD's doc is fairly good compared to Intel's. The example to enter
64-bit mode was of good help, though not complete (I had to figure how
to build the paging tables : a basic example of my program is
somewhere in win32asm board community, google at "valy" "os" etc if
interested with my asm source)

Best regards

Wiktor S.

unread,
Oct 5, 2004, 10:48:47 AM10/5/04
to
>> If it works on Bochs... ;-)
>>
> Nope. Sorry, I tried Bochs, this is great for 32-bit but it hangs as
> soon as I use CR4. It was 4 or 6 months ago. Paging is not an option
> with AMD64 long mode.

Now I see - your program (agner2.asm) displays PM16 and immediately reboots
on Bochs from current CVS.
Started saving money for real Ath64...

--
a_rien

e-mail: wswiktor&poczta,fm


0 new messages