DOS ain't dead

> 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.

> 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.

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!

> > 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

> > 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!
Make Russia small again!