This is a 8086 assembler written in MSDOS batch. It depends on just two utilities: RPN.COM and APPFB.COM, the rest is completely in batch.
This is wizardry, right?
This is a 8086 assembler written in MSDOS batch. It depends on just two utilities: RPN.COM and APPFB.COM, the rest is completely in batch.
This is wizardry, right?
There are tools for everything, and before people start screaming hate for Batch, there are sometimes benefits to using it that cannot be replicated with other tools.
I’ve written a two-thousand+ line batch file to handle the calling conventions of many different DOOM engines: https://github.com/Kroc/PortaDOOM/blob/57764e55773a0a2a480513cb0c338…
Being a Batch file, it will run on any machine without dependencies. The end user can examine the code at any time. It strings things together in a way that would be literally impossible in UWP or other app-distribution methods. It can be further scripted from other tools (so few GUI apps have any kind of automation at all). Also I made something from nothing that does the job.
So yes, this assembler in batch is plain wizardry and don’t be too quick to throw away the benefits of not having to have an installer, 30 MB of runtimes / dependencies and relying on a stack of frameworks a mile high.
Bit of a false dichotomy there. Free Pascal or Open Watcom C/C++ both support the relevant targets (real-mode DOS, DPMI DOS, Win32 console mode), with self-contained output binaries in the same size class, and they’re generally better-suited to these sorts of tasks.
When I can find time to get back to it, I’m working on an installer for DOS applications (since that’s the only kind of installer that never got a truly freeware/open-source offering akin to Inno Setup, NSIS, or WiX.) and I managed to put together a pretty nice-looking demo of my nice, Doxygen-documented API wrappers around BIOS int 10h functions which is only 1602 bytes when compiled to .com by OpenWatcom 1.9, with 996 bytes of that being the base overhead that is imparted on an empty void main(void) {} by statically linking Watcom’s C runtime.
https://twitter.com/deitarion/status/1057460614916960257
…and, back in the day, Watcom C/C++’s competitive strength was having the best optimizers.
Edited 2018-12-08 03:55 UTC
I’ve done a complete scriptable make engine in full batch because I wanted to get rid of dependencies. 45KB and voila : https://github.com/Kochise/makeit
So I understand your motives.
Yeah… No offence, I’m sure yours worked perfectly every time, or output very nice error messages when problems did arise.
However, I’ve been stuck with a large hodgpodge of bash that does a lot internally, occasionally starting up a few different perl self contained executables to do things.
I’m really tempted to rewrite in something sane. As you might expect, it was not done well. Constant bizarre errors, requiring research and debugging print statements interjected. Its a mess. So while there might be some “good” ones out there,I’d advise people to just use a proper powershell script or write a real application.
No problem, it was coded to solve a problem and it solved it perfectly. There’s still some quirks, but basically, I use it to do batch conversion using ImageMagick or lame (for instance) :
– – – conv_mp3.txt – – – – – –
LOC_BAT=c:\Program Files (x86)\Audacity
LOC_EXE=${LOC_BAT}\Lame For Audacity
LOC_SRC1=g:\_VOSTRO\_SON\_MINI
LOC_DST1=g:\_VOSTRO\_SON\_MP3
LOC_MOV=.\_TIF
convert=MP3_
MP3_EXE=lame.exe
MP3_URL=http://ryanve.com/lame/
MP3_URL=http://ecmc.rochester.edu/ecmc/docs/lame/switchs.html
MP3_CPU=-25%
MP3_SRC=${LOC_SRC1}
MP3_DST=${LOC_DST1}
MP3_CLI=LOC EXE ARG EXT TMP
MP3_EXT=wav
MP3_ARG=-b 128
#MP3_ARG=-V2 –vbr-new –quiet
MP3_TMP=”$[LOC_DST]\$[NAME].mp3″
– – – – – – – – – – – – – – – – – – – –
Then call makeit using : makeit convert conv_mp3
Simple, elegant, and the output folder allows you to scrutinize what happened at each step. But ok, a native application might be better…
I’ve written a similar lame script, in a couple different languages.
Java, c#, objective c, apple script, Python, and Perl maybe? Probably pascal as well…
Pascal… good stuff
All hail Niklaus Wirth! The extra credit question on every computer test I took in highschool.
But that’s really no different from distributing a standalone precompiled native binary. If you can run Batch, you can run a precompiled statically linked native program without dependencies either.
> This is an experiment in bootstrapping some sort of programming language or environment on a clean MSDOS install.
Everything in this bootstrapping assembler is a BATCH file… except for two critical utilities which are assembled by the native DOS assembler DEBUG.EXE. So not only does DOS already ship with an assembler, you have to use it to build the parts of this assembler it can’t do in BATCH files.
If one wanted to explore this space, IMHO a more compelling choice is to bootstrap a minimal foundation in Forth (or Forth-ish) and build whatever tooling is needed on top of that. JonesForth is an excellent example of doing exactly this, except for Linux:
Part 1: https://raw.githubusercontent.com/nornagon/jonesforth/master/jonesfo…
Part 2: https://raw.githubusercontent.com/nornagon/jonesforth/master/jonesfo…
There are assemblers that don’t require an assembler or compiler to bootstrap them?
I’m sure there exists some, but a vast majority do require some existing system to build them.
What do you mean, a turing complete language ? That’s the old chicken and egg problem. Since inputting data into a computer requires a form of hmi and a abstract syntaxt, you need something to process the data, transform them into machine code and stuff. The most self interpreted language might be running on lisp machines though.
I remember CHASM – a cheap assembler written in BASIC – which could be run on DOS based systems via the included ROM-BASIC (IBM-PC) or GWBASIC (any clone).
Written in MSDOS Batch, eh?
Psh. If you really want to impress me, write it in CSS.