DOS ain't dead

DX64 - open source 64-bit dos extender with a few examples how to use it.
Executables (ADAM format) can be compressed by 32LITE, UPX or LPACK.
To recompile sources you need modified by me FASM/VASM assembler.
There are four versions of the dos extender (two with support for 1GB
pages or not, and two as an external|internal stub-loader).
Choose the one that suits you.

It is possible to download files from (search DX64.7Z, FASM*.7Z files):
https://drive.google.com/drive/folders/0B_wEiYjzVkC0ZGtkbENENzF1Nms
or
https://board.flatassembler.net/download.php?id=7978

Have fun.

The Hello64.ASM source looks really horryfying. Is (in theory) possible to use some high-level language with your 64-bit stuff?
And it would be very helpful to heavy comment every line of the Hello64.ASM (and other demo sources).
Unfortunately I don't have any 64-bit CPU so I can't test your programs at all.

---
DOS-u-akbar!

> Is (in theory) possible to use some high-level language with your 64-bit
> stuff?
I use 64-bit pascal compiler (FPC) to create applications and convert result PE+ files to Adam format.
I also used DX64 for the 64-bit version of NDN (Necomancer's Dos Navigator).
> And it would be very helpful to heavy comment every line of the Hello64.ASM
> (and other demo sources).
I will write comments when I have more time.

> DX64 - open source 64-bit dos extender with a few examples how to use it.
> Executables (ADAM format) can be compressed by 32LITE, UPX or LPACK.
> To recompile sources you need modified by me FASM/VASM assembler.

it's very interesting.

However, on my Ryzen 5 your sample programs all show a similiar behavior: they start and display something onto the screen, but they don't react on keystrokes. I always have to reset the computer.

Without documentation it's virtually impossible to do something useful with the extender.

---
MS-DOS forever!

> However, on my Ryzen 5 your sample programs all show a similiar behavior:
> they start and display something onto the screen, but they don't react on
> keystrokes. I always have to reset the computer.

Some of these programs have a main loop that runs 8G times. If the program does not respond to pressing ESC, please wait 15 seconds for its completion.

> Some of these programs have a main loop that runs 8G times. If the program
> does not respond to pressing ESC, please wait 15 seconds for its
> completion.

Yes, for example the HELLO64.EXE program returns to the cmd prompt after a few seconds. But then the computer still doesn't react to key strokes and needs reset.

Did you reprogram the PIC and forget to restore it?

---
MS-DOS forever!

> Did you reprogram the PIC and forget to restore it?

PIC was reprogrammed at start but at default values 0x08 for master and 0x70 for slave.

In the Hello64.EXE program, new handle procedures for IRQ0, IRQ1, IRQ12 and Int1B, Int1C have been set. However, old routines are also called. Maybe something "interferes" with the mouse driver. I tested programs with QEMU and Bochs and they work for me. You can use the SD64.EXE debugger and trace the programs.

> I tested programs with QEMU and Bochs and they work for me.

Well, good, at least Qemu works "for me" also - didn't test Box.

However, the qemu keyboard emulation was "not so good" in 2007 when I played with it ( the HX Win32 emulation needs pretty low level access to the keyboard ) and my impression is that it hasn't improved much in the last 13 years. At the very least you shouldn't rely on qemu if you want your program to run elsewhere as well.

> You can use the SD64.EXE debugger and trace the programs.

Thanks, but this debugger shows just a black screen when I start it (in qemu and in true DOS ).

I was curious and took a brief look into Hello64.asm ( I didn't try to assemble because you mentioned that a "special" version of fasm is needed ). This code looks suspicious:


Int09h: inc     dword [dword 0xB8000+ScreenX*8]
        iretq

Int08h: push    rax
        inc     dword [dword 0xB8000+ScreenX*0]
        in      al,60h          ;Get char from keyboard
        cmp     al,81h          ;Esc released?
ifz     mov     [WasCtrlBreak],80h ; if yes, be ready from exit


It's probably a typo, but the keyboard is usually read by Int09 and the timer is handled by Int08 - your code looks as if you've mixed up those.

---
MS-DOS forever!

> Thanks, but this debugger shows just a black screen when I start it (in
> qemu and in true DOS ).

The debugger uses a special "unusual" 132x64 text mode based on Japheth's SETM48 and others sources. This may not work on all hardware.
I added qemu and Bochs detection to the debugger.

> It's probably a typo, but the keyboard is usually read by Int09 and the
> timer is handled by Int08 - your code looks as if you've mixed up those.

I thought you could read from the keyboard port 0x60 (not only in IRQ1) at any time. I have encountered this in many dos programs, where for "savings" you can read from this port.
I moved this part of the code to Int09 and uploaded new sources.

> I didn't try to assemble because you mentioned that a "special" version of
> fasm is needed.

To recompile sources you need to download from my google drive for example the file FASM172.7Z

> I moved this part of the code to Int09 and uploaded new sources.

Thanks! However, no change, still the keyboard is locked. And it also happens with your TEST64.exe, which, AFAICS, doesn't modify IRQ vectors. So it may be a bug in the D3X extender?

[edit] I checked on an Intel quad core and it worked there! My previous, failing tests were both on AMD machines.

> I thought you could read from the keyboard port 0x60 (not only in IRQ1) at
> any time. I have encountered this in many dos programs, where for "savings"
> you can read from this port.

You "can" of course read this port, but

- you should check BEFORE the read that data is ready (bit 0=1 of port 61h (or 64h? - I can't remember)).
- reading port 60h is kind of sending "EOI" to the keyboard controller.

---
MS-DOS forever!

> - you should check BEFORE the read that data is ready (bit 0=1 of port 61h
> (or 64h? - I can't remember)).
> - reading port 60h is kind of sending "EOI" to the keyboard controller.

Really?
Because in Blocek I hook the keyboard IRQ/INT interrupt, read the port 60h and then call the original DOS handler and everything works fine (FreeDOS/MSDOS/Win98/WinXP)

---
DOS-u-akbar!

> Really?
> Because in Blocek I hook the keyboard IRQ/INT interrupt, read the port 60h
> and then call the original DOS handler and everything works fine
> (FreeDOS/MSDOS/Win98/WinXP)

Yes, INSIDE the IRQ 1 handler you can be sure that the data at port 60h is ok to read. But even then it's a small problem, at least in virtual environments - to work correctly, the host has to implement a small delay until it sends the next byte to the port.

The recommended and safe way is to hook int 15h, ah=4Fh.

---
MS-DOS forever!

> However, no change, still the keyboard is locked. And it also
> happens with your TEST64.exe, which, AFAICS, doesn't modify IRQ vectors. So
> it may be a bug in the D3X extender?

I think I found the reason, unnecessary instruction:

and [dword 417h],word 0x00F0

In addition, I turned on interrupts (sti) right after jump to long mode.
It should work now. Thanks.

> It should work now. Thanks.

As I mentioned in my previous post, AFAICS it works on Intel cpus - the problems occur with AMD only. Your last modifications did not change that.

---
MS-DOS forever!

> It is possible to download files from (search DX64.7Z, FASM*.7Z files):
> https://drive.google.com/drive/folders/0B_wEiYjzVkC0ZGtkbENENzF1Nms
> or
> https://board.flatassembler.net/download.php?id=7978
>
> Have fun.

I downloaded DX64.7Z, but i cannot unpack.
Tried 7z, winzip and rar, always getting a message stating that the file either is not e valid archive or is corrupt.
How can I work around?
Thanks for attention.

CandyMan uses for packaging some very new verson of 7-zip. I am not able to open his archives with usual 7-ZIP 9.22 but I have some DOS build of 7-ZIP 15.x which can do this job.

---
DOS-u-akbar!

> CandyMan uses for packaging some very new verson of 7-zip. I am not able to
> open his archives with usual 7-ZIP 9.22 but I have some DOS build of 7-ZIP
> 15.x which can do this job.

I used the very last release 7-zip 21.07 and also tried realise 15.05 (who knows?) but the result is quite the same.

> > You can use the SD64.EXE debugger and trace the programs.
>
> Thanks, but this debugger shows just a black screen when I start it (in
> qemu and in true DOS ).

I think I had reported this too. Probably nobody else with non-ancient VGA has this rare videomode. Is there available some version with e.g. std. VGA 80x50 as fallback?

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

Hello!

> Executables (ADAM format)

Did you have ths format (ADAM) specification (description etc) ?
Could you, please, share it with me?

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> > Executables (ADAM format)
> Did you have ths format (ADAM) specification (description etc) ?

O. I am find it. Sorry. I made a very stupid mistake - mix DOS32 and DOS32A. It is different extenders. Adam was described into dos32.doc (need lookup dos32v33.zip):

Executable format and loading process.

The information here will explain how DOS32 and DLINK work together
and exactly what happens when the executable is first ran from DOS to
when the application's first instruction is executed. Please note that
it is not essential for you to know these details but is described here
for those of you who are interested.

File format of a DOS32 executable (.EXE file produced from DLINK)

Offset    Size           Description
0         n    A stub loader or DOS32.EXE of n bytes  {no stub in DLL}
n+0       4    Signature "Adam"     { ="DLL " for DLL files }
n+4       2    DLINK version in packed BCD format
n+6       2    Minimum DOS32 version required (packed BCD)
n+8       4    Number of bytes remaining after the stub file.
               The entire .EXE file size (after linking) will be equal
               to this value plus the stub file size.
n+0Ch     4    Start of 32bit executable image relative to the 'Adam'
               signature.
n+10h     4    Length of executable image ( see below ).
n+14h     4    Initial memory required for application. This value
               must be larger than the size of the 32bit executable
               image.
n+18h     4    Initial EIP  { public varible address for DLL file }
n+1Ch     4    Initial ESP  { ignored in DLL header }
n+20h     4    Number of entries in fixup table. Each entry
               in the table contains a 32bit offset relative to the
               start of the executable image of a 16bit WORD that must
               be set to the programs data selector at load time. The
               table immediately follows the executable image.
n+24h     4    Flags  ( function active when bit is set )
                 bit 0    = executable image is compressed
                 bit 1    = display DOS32 logo when executed
                 bits 2..31 reseved.

The 32bit executable image (application binary data) can start anywhere
after this point (i.e >= offset n+28h in the .EXE file).

--- more entries can be added in future ----

At the front of the .EXE is the stub loader or DOS32.EXE file and
must be a normal DOS executable ( i.e start with a 'MZ' signature ).
When the .EXE is executed, DOS will only load and execute the 'MZ'
executable at the front of the file and ignore the rest of the file. The
stub loader is a small program that will simply execute DOS32.EXE. I
have distributed a sample stub loader, STUB.ASM. This actual program is
stored internally in DLINK and is automatically used as the stub if
the -S option is not used. See later in this document for more
information about the -S switch.

When the program DOS32.EXE is executed it will first initialise for
protected mode and try an load in the 32bit application. It does this by
first checking at the end of the it's self for the 'Adam' signature. If
found it will then assume that it is a DOS32 32bit executable and read
the rest of the header and begin loading the application it into memory.
If no 'Adam' signature was found it will then look at parent program
which had executed DOS32.EXE. If the parent program has the 'Adam'
signature then it will begin loading the executing the DOS32 executable.
If the parent does not contain the signature then the following error
will be displayed.

DOS32 Version 3.xx 32bit DOS-extender and loader
Copyright (c) Adam Seychell, 1994. All rights reserved.

File name: C:\DOS32.EXE

Error: Bad DOS32 executable

With this set up it allows DOS32.EXE to be used in place of the
stub loader. If a stub loader is used, and the user runs the .EXE, the
stub file will be executed which in turn will execute DOS32.EXE. DOS32
will then begin it's work, by first initialising for protected mode
operation and allocate a memory block for the application. The
executable image is then loaded into the memory block followed by
applying the selector fixups. Finally the stack pointer (SS:ESP) and
instruction pointer (CS:EIP) are set to finally start the application up
and running.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> > It is possible to download files from (search DX64.7Z, FASM*.7Z files):
> > https://drive.google.com/drive/folders/0B_wEiYjzVkC0ZGtkbENENzF1Nms
> > or
> > https://board.flatassembler.net/download.php?id=7978
> >
> > Have fun.
>
> I downloaded DX64.7Z, but i cannot unpack.
> Tried 7z, winzip and rar, always getting a message stating that the file
> either is not e valid archive or is corrupt.
> How can I work around?
> Thanks for attention.

Unpack it with UHARC (Uwe Herklotz ARChiver).

---
Glory to God for all things

> > I downloaded DX64.7Z, but i cannot unpack.
> > Tried 7z, winzip and rar, always getting a message stating that the file
> > either is not e valid archive or is corrupt.
> > How can I work around?
> > Thanks for attention.
>
> Unpack it with UHARC (Uwe Herklotz ARChiver).

Many thanks! UHARC solved the problem.
I wonder why the archive has been named DX64.7z instead of DX64.uha, since it is now clear that CandyMan used Uharc for compression.