X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: "Rod Pemberton" Newsgroups: comp.os.msdos.djgpp Subject: Re: Dos programming Date: Fri, 20 Mar 2009 04:33:29 -0400 Organization: Aioe.org NNTP Server Lines: 139 Message-ID: References: <06c3c085-f8d3-497f-8f68-3db8518f7938 AT e18g2000yqo DOT googlegroups DOT com> <6ecec264-3874-47ef-b9d7-406f29d72679 AT s20g2000yqh DOT googlegroups DOT com> <4f7b4d8f-fa46-43d0-813f-1f37466aa3ce AT v38g2000yqb DOT googlegroups DOT com> <387c477c-acc2-45ff-bfd2-382f85cccf29 AT e38g2000yqa DOT googlegroups DOT com> NNTP-Posting-Host: pldq+kT97bAAp/ObDwnZyQ.user.aioe.org X-Complaints-To: abuse AT aioe DOT org NNTP-Posting-Date: Fri, 20 Mar 2009 08:30:33 +0000 (UTC) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933 X-Notice: Filtered by postfilter v. 0.7.7 X-Newsreader: Microsoft Outlook Express 6.00.2800.1933 Cancel-Lock: sha1:AqDiwoX/1A4ARMziZzdlM2Q7g1w= X-Priority: 3 X-MSMail-Priority: Normal To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com "Rugxulo" 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