Mail Archives: djgpp/2009/03/20/03:46:24
"Rugxulo" <rugxulo AT gmail DOT com> wrote in message
news:387c477c-acc2-45ff-bfd2-382f85cccf29 AT e38g2000yqa DOT googlegroups DOT com...
> > 486dis_c.zip by Robin Hilliard (and from code by DJ Delorie and Kent
> > Williams)
>
> Honestly, the only disassemblers I use (besides GRDB) are ndisasm,
> objdump -d -M intel, and BIEW (which can view or disassemble to file).
Sure. I use ndisasm almost exclusively too (some objdump and some WDIS).
But, this old package compiled easily, and extends easily. It might not be
someone's first choice for a _standalone_ disassembler. But, there are
other places where disassemblers are used: debuggers, binary translation,
code rewriters, program directed.
> > fhard101.zip by Aaron L. Brenner
> > - driver to emulate a small HD using floppies, assembly, Public Domain
>
> Emulate a HD by what, manually swapping floppies? No,
The driver code is what is important. What the driver was originally
programmed to do isn't... Basically, it's useful as a base template for DOS
.sys driver of your design.
AFAICT, there aren't many DOS .sys device drivers with source. I think
that's the only one I've found that's Public Domain (not copyrighted).
Could you code a DOS .sys driver by from scratch using the IBM PC DOS 7
Technical update and RBIL?... ;)
E.g., while my version of the driver needs some more work to be useful or
released, it's emulating the logical floppy operations while using a
physical floppy. So, I have access to the floppy as both A: and F: at the
same time. I can completely monitor all logical (implemented) and physical
(unimplemented) driver access to the F: floppy disk. I can compare the disk
image on F: with A: to determine if programs which accessed the disk
function identically. Do they read or write the same data? Do they read
and write using the same logical or physical operations? If I wanted, I
could determine exactly how DOS maps it's 0x21 and 0x2f function floppy
calls to BIOS calls. One could do this with a harddisk driver too. Or, I
could, using 0x2f, install an ext2 or other filesystem allowing DOS to
access non-FAT floppy disks. Or, I can rework the driver to create a device
of my own, say a ramdisk, either as a floppy or harddisk. And, the driver
will work both in DOS and Win98SE.
> > ddl.zip by P. Frost
> > - command line device driver loader, copyrighted
>
> FreeDOS has a good one called devload.
IIRC, devload doesn't allow _unloading_ a device driver. ddl.zip has three
utilities: ddl, ldd, ddu, which are load, list, and unload respectively. I
also recall having another problem with devload, but I don't recall what
that was. I know I've had a few problems with ddl. E.g., on my old PC, I
used devload to load USB drivers because ddl wouldn't load them. I'm not
sure if that was a bug with ddl, or if the USB device drivers didn't comply
with the spec.'s for device drivers. The quirk of ddl is uppercase only.
IIRC, one of the ddl bugs is it won't load a device driver that has multiple
device driver headers. This is not a big issue since most aren't
constructed that way.
> > x2b11.zip
> > - exe2bin replacement, assembly, Public Domain
>
> Some linkers will do this for you. Also, OpenWatcom has one (FreeDOS
> uses it).
Right, but that's not what's important. Any simple and small .exe, one that
can be properly converted into a .com, can be executed in memory directly
after the conversion. Basically, any "exe2bin" or "exe2com" is a stripped
down OS executable loader.
> I assume you know of Bob Stout's snippets page?
>
> http://www.snippets.org/
Yep.
> > I'd suspect you could also build a large
> > collection of DOS text editors too. They should still work too.
>
> I've collected a bunch of those, and most of the best ones were
> compiled by DJGPP. ;-)
>
> http://board.flatassembler.net/topic.php?t=6267&start=20
I see one for DJGPP not on that list. It's in the DJGPP contrib
directories. With a few code tweaks that are disabled by default, it looks
identical to MS-DOS EDIT... However, I'm not sure it was compiled with
DJGPP. When I tried to recompile it, it didn't work. There were some NULL
pointer issues. Anyway, look for SMEDIT by Prashant TR.
Well, the best one, IMO, for programming, not for text or document
formatting, is MS-DOS EDIT. I also use a DOS VI clone since supports EX or
ED editor commands. The VI clone actually starts up a DOS ELVIS clone.
Typically, I just use this to insert or delete at the beginning or end of
lines, or do repetitive line processing, since supports EX or ED editor
commands. And, I use one called QED, which isn't available anymore, for
simple and small hex edits. It's easier to use than my hex utilities.
> > Much of the other stuff is obsolete or trivial or copyright restricted
or in
> > Pascal... etc.
>
> There is no such thing as obsolete, only what works and what doesn't
Well, I hope you take from my replies above that even if it doesn't
currently work, the source code can still be valuable if recycled for
similar tasks... That's almost always the perspective with which I'm
looking at these old packages. While I've found some, I've been really
hoping to find some great Public Domain C code from the Amiga's, like
complete compilers and compiler or graphics libraries.
> It's not as slow as they think, and it still works! They just can't be
> bothered. (Same with assembly, it's not dead, just it doesn't suit
> them.)
Most OSes need to use 16-bit code to access VESA video BIOS functions
anyway. It should be possible to write fast binary emulation or binary
translation with binary optimization. After a few runs, the code begins to
run at near native speeds. This could be similar to how FX!32 worked.
FX!32 ran non-native applications very slowly at first. Then, any part of
the application you already ran, ran well since it had been translated and
optimized. After 5 to 10 runs using different parts of the application,
they ran very quickly. With binary translation, DOS becomes a 32-bit
sublayer or low-level "library" with minimal overhead. I.e., you don't code
a new 32-bit DOS. You let the translator recode a 16-bit DOS as a 32-bit
DOS for you... It'd be a bit like QEMU's instruction translation, but it
should be faster and more permanent. I don't know how well Scitech's x86emu
performs, but they use it in LinuxBIOS project. Your other options for
running 16-bit code as an OS component are 1) cpu's v86 mode, for which code
by many authors are available, but none are Public Domain, AFAIK, 2)
DOSBOX's 286 emulation code, and 3) QEMU or BOCHS emulation code
Rod Pemberton
- Raw text -