GZIPDATE.REX (uses TOUCH) / Tim Paterson / DOS v3 required (Developers)
> > > sure it didn't assemble something incorrectly. (NDISASM to the
> rescue!)
> > I properly tried NDISASM for the first time yesterday and to be honest
> I wasn't that impressed.
> It's nice for small projects. I probably wouldn't use it for anything
> big.
Well from my quick tests it didn't even appear to support skipping of DOS EXE headers by default! Yes, I realize NDISASM is cross-platform. However I assume this unfortunate omission also applies to ELF files as well? Ok, so the -E option can be used to skip programs headers but obviously one needs to know where the code starts which for most people means needing other tools...
Since there are other tools that will skip headers by default then clearly this then begs the question of why bother using NDISASM to do half the job when other tools exist which can do the full job? Still I am grateful to the developers of NDISASM for it's existence, however it clearly needs more work.
> CP/M was 8-bit, hence 16-bit was a bit jump up. But yeah, DOS was meant to
> be somewhat "compatible", imagine that! (BTW, Tim Paterson is obviously one
> smart guy, see his blog.)
Indeed, thanks for this reminder of some very interesting/informative posts on the subject of DOS by the one man who obviously knows DOS better than most:
http://www.patersontech.com/dos/articles.aspx
http://dosmandrivel.blogspot.com/
> From what I've heard, DOS 3.3 was the
> most popular until 5 came around (first to have an upgrade version).
Yes, as a DOS user already at the time Version 5 came out I would agree with this. Version 5 was a big leap forward with built in help etc. I remember being jealous of a family member when they got it and I was stuck with v4.01 !
> I think DJGPP apps require DOS 3.
I strongly suspect this will be the case. Indeed with most programs (particularly EXE files) if you do a HEX search for the following byte sequence B430CD21 - the DOS version check:
mov ah, 30h
int 21h
you will usually note that most programs (due often to their run-time libraries) are checking for version 3 or above. For example the following Turbo Pascal 7 "Hello World" program does this check if compiled with the standard system run-time library:
Begin
Writeln('Hello World', ParamStr(1));
End.
the following version check code will be generated:
B430 mov ah,030
CD21 int 21
3C03 cmp al,003
B80000 mov ax,00000
7225 jb 0000079B
whereas this very similar program doesn't include that version check:
Begin
Writeln('Hello World!');
End.
Why the difference on such a simple program? Well as you probably know, command-line parameters are stored in the program segment prefix - unfortunately Int 21/AH=62h - GET CURRENT PSP ADDRESS was introduced in DOS version 3! Thus most compiler run-times need version 3 for example in order to support command-line parameters! Prior to that DOS call there were other ways to support command-lines but many were complex or undocumented, e.g. Int 21/AH=51h DOS 2+ internal - GET CURRENT PROCESS ID (GET PSP ADDRESS) remained "undocumented" until DOS version 5. [See also comment below re COM files]
> It's not a stretch anymore. Obviously FreeDOS is freely available,
> so upgrading is pretty painless.
> I imagine that only old old machines where you can't (easily) upgrade
> would be the main problem, but those are rare.
Yes, it depends on your hardware. I have some boxes where early versions of DOS boots from silicon and booting other OS's is NOT supported. I have code which "kills" an existing DOS session allowing one to load a bootloader etc, yes similar to LOADLIN. I haven't tried it yet but in theory I should be able to use my code to boot something like FreeDOS. It is a small feature I am planning to add into RJDOS (along with a RUN feature which has a interrupt table loader/restore feature) but currently they are 3 separate pieces of code. However I thought others would find these features useful; hence my planned inclusion into RJDOS for this very reason.
> He started it in 1989, which probably explains why he bothered to support
> DOS 2!
Check to see how he is supporting command-line parameters. I'd be interested to know. If it is a COM file, he may be doing it simply by poking straight into the PSP as the simple example in Wikipedia demonstrates:
http://en.wikipedia.org/wiki/Program_Segment_Prefix
Complete thread:
- TOUCH.COM 1.4.3 (minor fix: debug script) - Rugxulo, 02.03.2010, 01:10 (Developers)
- GZIPDATE.REX (uses TOUCH) - Rugxulo, 02.03.2010, 01:22
- GZIPDATE.REX (uses TOUCH) - Arjay, 11.03.2010, 17:09
- GZIPDATE.REX (uses TOUCH) - Rugxulo, 11.03.2010, 19:41
- GZIPDATE.REX (uses TOUCH) - Arjay, 18.03.2010, 16:31
- GZIPDATE.REX (uses TOUCH) - Rugxulo, 19.03.2010, 00:58
- GZIPDATE.REX (uses TOUCH) - Arjay, 22.03.2010, 00:40
- GZIPDATE.REX (uses TOUCH) - Rugxulo, 22.03.2010, 17:47
- GZIPDATE.REX (uses TOUCH) / Tim Paterson / DOS v3 required - Arjay, 23.03.2010, 16:25
- GZIPDATE.REX (uses TOUCH) / Tim Paterson / DOS v3 required - Rugxulo, 23.03.2010, 16:59
- [deleted] - Arjay, 23.03.2010, 19:32
- TOUCH 1.4.4 - Rugxulo, 07.04.2010, 00:05
- [deleted] - Arjay, 23.03.2010, 19:32
- GZIPDATE.REX (uses TOUCH) / Tim Paterson / DOS v3 required - Rugxulo, 23.03.2010, 16:59
- GZIPDATE.REX (uses TOUCH) / Tim Paterson / DOS v3 required - Arjay, 23.03.2010, 16:25
- GZIPDATE.REX (uses TOUCH) - Rugxulo, 22.03.2010, 17:47
- GZIPDATE.REX (uses TOUCH) - Arjay, 22.03.2010, 00:40
- GZIPDATE.REX (uses TOUCH) - Rugxulo, 19.03.2010, 00:58
- GZIPDATE.REX (uses TOUCH) - Arjay, 18.03.2010, 16:31
- GZIPDATE.REX (uses TOUCH) - Rugxulo, 11.03.2010, 19:41
- GZIPDATE.REX (uses TOUCH) - Rugxulo, 07.04.2010, 01:06
- GZIPDATE.REX (uses TOUCH) - Arjay, 11.03.2010, 17:09
- GZIPDATE.REX (uses TOUCH) - Rugxulo, 02.03.2010, 01:22