Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

32-bit MSDOS (Announce)

posted by kerravon E-mail, Ligao, Free World North, 28.06.2021, 07:30

> I welcome any development of a possible UEFI-replacement for DOS, and the
> elegance of your "32-bit MSDOS" seems like it one day will surmount the CSM
> / BIOS limitations which a 16-bit MSDOS imposes.
Surely if we're going to involve UEFI, the first
thing we should have is a UEFI that simply restores
the basic BIOS services?

That then makes all BIOS-dependent OSes work, not
just "32-bit MSDOS".

> Memory and file systems supported? FAT32, EX-FAT, NTFS? Is it in fact
What memory are you talking about? Currently I
just call the BIOS to get the extended memory
size, which gives me enough to run gccwin, but
it is my intention to get the proper memory
map so that I have access to nearly 4 GiB or
whatever. It just hasn't been a priority.

FAT-12, 16, 32 are supported. Note that FAT-32
and LFN was entirely written by an 18-year old
girl called Alica from Slovakia.

> file-system agnostic?
In what way? My main focus is on C90, so most
applications I care about do not know what
the file system is.

> Getting away from Microsoft standards is important,
> but so is backward compatibility with extant filesystems. Does it support
> unsigned long access to files natively, ie able to access files from 2 GiB
> to 4 GiB-1?
C90 is limited to seeking to a "long", so I don't
want to get involved in kludges to exceed that.

To exceed that my intention is to change gccwin
so that "long" (only) is 64-bit. Using 80386
instructions still.

> How about access to PAE memory as has been done with Japheth's
> XMS 3.5 protocol, for example.
I don't know what PAE is. Alica added paging,
but my only interest in paging is to switch
it off so that V=R and I return to a simple,
understandable system. Then when an exception
like divide by zero occurs, I will be able to
print an MVS-style dump that includes stack
traceback.

Note that over the weekend I discovered that
Windows has the ability to do the equivalent,
it's just not enabled by default.

It starts with this PowerShell script:

enabdump.ps1:
New-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows\Windows Error
Reporting" -Name "LocalDumps"
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\Windows Error
Reporting\LocalDumps" -Name "DumpFolder" -Value
"%LOCALAPPDATA%\CrashDumps" -PropertyType "ExpandString"
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\Windows Error
Reporting\LocalDumps" -Name "DumpCount" -Value 10 -PropertyType DWord
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\Windows Error
Reporting\LocalDumps" -Name "DumpType" -Value 2 -PropertyType DWord

and then you match it with windbg, link maps
and assembler listings (with offsets) of your
C code.

Probably a majority of the time you will be able
to solve a production problem with a single
crash, instead of needing to be able to reproduce
the problem in dev.

Note that I have a plan to change gccwin to save
all registers on function entry, and save the EIP
and function name by doing a "call", so that the
entire stack traceback is predictable. That's how
to match MVS convention which I like.

BFN. Paul.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22632 Postings in 2109 Threads, 402 registered users, 428 users online (1 registered, 427 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum