Animator-Pro VS MS-DOS

I like to start up Dosbox-X or one of the virtual Amiga environments that comes bundled with Amiga forever. Definitely cozy.

More often I use some old application, like the nowadays BSD-licensed ex-Autodesk Animator. It is fun to figure it out and more fun than modern applications in many ways. I even bought an old used book about it and read cover to cover. Limited compared to modern graphics software, but "cozy" is a great way to describe the experience.

https://github.com/AnimatorPro/Animator-Pro

But I think very limited and objectively worse GUIs can be fun for inspiration and to get other styles. I love to play around with Autodesk Animator. The workflow is kind of awkward but being forced to always think ahead of what you want to do and compose images of small parts (because there are no layers and many other limitations) it becomes more like a fun puzzle/game to get anything done (and the resulting FLI files can be imported into Aseprite for more serious editing!).

Other tools may be a bit more lacking. Not sure if any reasonably modern version control system works. Graphics editors will be a bit old (but Autodesk Animator was released open source and is quite great really and no idea how fun sfx editors and other gamedev tools from last century are to use today.

Autodesk Animator can save and load PIC files. But it looks like your header is different from what I see in one of those I happened to have.

Was it https://github.com/AnimatorPro/Animator-Pro ?

I took the time a few years ago to learn a bit about how to use Autodesk Animator (it was released with a BSD license some ~10 years ago and can be downloaded legally for free these days). Was really impressed with the GUI. Just press a single key to open the menu that begins with that letter, then the first letter of the menu-item you want to use. They managed to use only words that begin with unique letters while still making a lot of sense. Plus some other single-key shortcuts. And many, to me, unusual design choices everywhere, but it all makes sense and is consistent in a way that after a few hours I was not bothered at all by the fact that nothing was like a modern GUI, and there was definitely nothing about using more modern GUI conventions I can think of that would make it more pleasant to work with.

https://github.com/AnimatorPro/Animator-Pro

Wild guess is that a GIF without a color table would typically render using the default VGA palette back in the day? I tried to open it in dosbox in PictView but it displayed that GIF in grayscale (not all black at least!) (that application is from 2015 though and might not be representative for how real 1989-era applications would have done?). Then I tried the "crop" tool that comes with Autodesk Animator, because I know the application itself only supports GIF87a in 320x200, but crop also said the image had unknown version.

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