GW-BASIC VS MS-DOS

Fun fact...Microsoft open sourced GW-BASIC under the MIT license a couple years ago...

https://github.com/microsoft/GW-BASIC

The blog post announcing it is here if you want more information about it...

https://devblogs.microsoft.com/commandline/microsoft-open-so...

I'm way ahead of you :)

Unfortunately, rewriting it without reverse engineering makes it almost impossible to reach the same performance characteristics. These are essential to reproduce proper timing in several games.

Also, it may not be much code, but the floating point operations are quite a piece of art. See the GW-BASIC source code, which is somewhat similar [1].

I also rewrote most of the BASIC interpreter directly in Kotlin, omitting assembly, but obviously that runs into the same compatibility issues.

As far as I understand it, reverse engineering is not allowed without permission, although some people suggest that it is ok to get other software to run. Not sure whether that case would hold up for my entertainment value.

[1] https://github.com/microsoft/GW-BASIC/blob/master/MATH2.ASM

Someone could take this and try to make it ROM-able in order to "complete" the BIOS:

https://github.com/microsoft/GW-BASIC

Hey! They use an emulation. You can implement this yourself but it's quite the undertaking if you also want trigonometry functions etc. There are libraries available but they can be hard to build on older compilers, search for floating point emulation c library to get some ideas. Depending on what you want to do however are you sure you need floating point? I thought so in the past but have reconsidered. Many times you can work something out by either scaling or smart fractions like 355/113 for pi etc. Regarding scaling, this is also how fixed point math works, certainly also of interest and maybe more then enough?

> but if ever the source for QBasic leaked

QBasic? - Why that modern thing. Just use the proper BASIC: https://github.com/microsoft/GW-BASIC ;)

Microsoft GW-Basic Interpreter Source Code\ (20 comments)

This 4.0 code contains references to 4.00, though: https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/BOOT/...

I recently stumbled across the MS-DOS 1.25 and 2.0 source code [1].

[1] https://github.com/microsoft/MS-DOS

“Despite this reduction in scope for MS-DOS 2.0, it did carry many bits of XENIX. The system adopted I/O redirection via less-than and greater-than symbols, piping, a hierarchical directory tree, file handles […]”

The source code for MSDOS 2 is available and the file descriptor stuff appears to be in https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/... and XENIX2.ASM. It stands in contrast to the File Control Block API which MSDOS 1 (née 86-DOS) modeled after CP/M’s API.

Asynchronous I/O figures in prominently in Windows NT. I was really surprised to see[0]:

Each driver in the chain defines two entry points; the strategy routine and the interrupt routine. The 2.0 DOS does not really make use of two entry points (it simply calls strategy, then immediately calls interrupt). This dual entry point scheme is designed to facilitate future multi-tasking versions of MS-DOS. In multi-tasking environments I/O must be asynchronous, to accomplish this the strategy routine will be called to queue (internally) a request and return quickly. It is then the responsibility of the interrupt routine to perform the actual I/O at interrupt time by picking requests off the internal queue (set up by the strategy routine), and process them. When a request is complete, it is flagged as "done" by the interrupt routine. The DOS periodically scans the list of requests looking for ones flagged as done, and "wakes up" the process waiting for the completion of the request.

I didn't realize that kind of forwarding-looking perspective was going into the design of MS-DOS.

[0] https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/...

>Any others I'm missing?

I would suggest MS-DOS: https://github.com/microsoft/MS-DOS