Dos programming
themouse
I have been programming for 13+ years but its all windows.
The language is not that important. I am familar with many except
assembly.
Need a start for that too eventually but not yet unless its the best
way
to rewrite an x server for DOS.
Gerrit van Niekerk
> Anyone know of any working links to programming in DOS?
themouse
> On Tue, Mar 17, 2009 at 4:39 PM, themouse <usul.the.mo...@gmail.com> wrote:
> > Anyone know of any working links to programming in DOS?
>
> http://www.frontiernet.net/~fys/index.htm
Thank you
~themouse
alex bodnaru
Hash: SHA1
hi mouse,
give a look here http://www.microwindows.org/
good luck :) .
- --
- --
best regards,
alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iJwEAQECAAYFAkm/2DoACgkQ2nA3WyrfyeMtqgP/YsyCV4h91GKCjve69zGuhE1b
UDooTnzRjigoiFlQEpY1QEGffLCzfkZF5CvUARhNuJyj/RcpfNs8eP/FaX2Kcukn
4T+PnZf5MRaMQIpaEaW67VFLbxfT9xnawOrbp6RRxhYLOwJdX44Uxp/CSm0raBoT
7GZU6qkZ+vweHny/lm0=
=k0Tj
-----END PGP SIGNATURE-----
themouse
(Im at work and only have a few minutes here and there so haven't read
everything yet)
Looks like the project has only lists which I am not fond of LOL I
like forum format.
Besides I don't want to go in there asking dumb questions LOL.
Limit the dumb questions to one forum/group etc :P
~theMouse
Rod Pemberton
news:06c3c085-f8d3-497f...@e18g2000yqo.googlegroups.com...
> Anyone know of any working links to programming in DOS?
IBM's PC DOS 7 Technical Update:
http://www.redbooks.ibm.com/redbooks/pdfs/gg244459.pdf
Ralf Brown's Interrupt List (aka RBIL):
DJ html: http://www.delorie.com/djgpp/doc/rbinter/
MP html: http://www.ctyme.com/rbrown.htm
RB files http://www.cs.cmu.edu/afs/cs/user/ralf/pub/WWW/files.html
HelpPC http://heim.ifi.uio.no/~stanisls/helppc/
Dave Williams DOSREF33. Search for dosref33.zip. (Simtel and Garbo
mirrors, DOS sites etc.).
Also, search for dospgref.zip.
You might also want to find copies of the DPMI 0.9 and 1.0 specifications,
and perhaps LIM EMS.
Rod Pemberton
themouse
> "themouse" <usul.the.mo...@gmail.com> wrote in message
>
> news:06c3c085-f8d3-497f...@e18g2000yqo.googlegroups.com...
>
> > Anyone know of any working links to programming in DOS?
>
> IBM's PC DOS 7 Technical Update:http://www.redbooks.ibm.com/redbooks/pdfs/gg244459.pdf
>
> Ralf Brown's Interrupt List (aka RBIL):
> DJ html:http://www.delorie.com/djgpp/doc/rbinter/
> MP html:http://www.ctyme.com/rbrown.htm
> RB fileshttp://www.cs.cmu.edu/afs/cs/user/ralf/pub/WWW/files.html
>
>
> Dave Williams DOSREF33. Search for dosref33.zip. (Simtel and Garbo
> mirrors, DOS sites etc.).
>
> Also, search for dospgref.zip.
>
> You might also want to find copies of the DPMI 0.9 and 1.0 specifications,
> and perhaps LIM EMS.
>
> Rod Pemberton
Great! TYVM!
~theMouse
Rugxulo
On Mar 17, 8:48 pm, themouse <usul.the.mo...@gmail.com> wrote:
> On Mar 17, 8:42 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> > "themouse" <usul.the.mo...@gmail.com> wrote in message
>
> >news:06c3c085-f8d3-497f...@e18g2000yqo.googlegroups.com...
>
> > > Anyone know of any working links to programming in DOS?
>
> (snip bunch of useful links)
>
> > Rod Pemberton
>
> Great! TYVM!
> ~theMouse
Well, at the risk of overwhelming you, here's some more:
http://ftp.lanet.lv/ftp/mirror/x2ftp/msdos/programming/specs/
http://ftp.lanet.lv/ftp/mirror/x2ftp/msdos/programming/gpe/
http://www.eunet.bg/simtel.net/msdos/asmutl-pre.html
Note that some of those files are older versions (i.e. newer exists),
but overall it's pretty useful as is anyways. And there are of course
a bunch more, but this should keep you busy. But I do suggest you
focus on only a few things initially so as not to spread your self too
thin.
P.S. DJGPP FAQ and libc reference are extremely useful too. DPMI and
VESA specs are definitely some things you should check out ... and
also a quick glance at PCGPE might be vaguely interesting too. Most
importantly, though, check out srcs to other DJGPP apps (GNU Emacs ->
EM2005S.ZIP, libc -> DJLSR204.ZIP, Allegro -> ALL422S.ZIP, etc. etc.).
For assembly, (if you're bored or run into something ... somewhat
unlikely), check out pmtut002, debugtut, primer2, and FASM's forum
(supports COFF among others, very very nice DPMI DOS IDE which
assembles itself), which is extremely helpful and has examples and
good info. http://board.flatassembler.net
Rod Pemberton
news:6ecec264-3874-47ef...@s20g2000yqh.googlegroups.com...
> Well, at the risk of overwhelming you, here's some more:
Ok. Well, if he just wanted to browse through collections of old DOS code
packages, there are more links:
ftp://ftp.funet.fi/pub/
http://www.zcu.cz/ftp/
http://hobbes.nmsu.edu/
http://www.os2bbs.com/Download/index.html
http://www.digsys.bg/simtel.net/msdos/index-msdos.html
http://archives.thebbs.org/
http://www.math.utah.edu/pub/
http://sac-ftp.externet.hu
;)
Rod Pemberton
Ste...@aol.com
themouse
> are there suitable discussion groups for DOS-programming
> with good traffic ?
the ones I have looked at seems to most tell me how to increase my
size
instead of how to determine the size of an array. :P
like I mention before I have my own web hosting company I could
create a website for free which have more modern forums etc.
we could then just start collecting dos programs, and dos programming
information.
just a thought.
~theMouse
Ste...@aol.com
themouse
:) thats the easy part. post links in forums and usenet groups,
register with yahoo, google, ms live search etc.
I use DotNetNuke so there are modules for most of that including
referal, social networking. webrings etc.
if that fails then google ad words. to show up at the top of the Dos
search list and links would be cheap as there are only a handful
of sites. but normally for the small business clients that isn't even
nessesary.
there is a little effort involved in promoting. thing in our favor
would be lack of compitition. :)
~theMouse
Rugxulo
On Mar 18, 3:01 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
Rod, I trust your experience here. So I'm sure you're aware that
Simtel lacks much (or is outdated) making it not too useful anymore.
Most OS/2 sites (even Hobbes) lack some current stuff, and what is
there (even EMX-compiled) doesn't usually work in DOS. And SAC mirrors
are good (now), but I've had to send a billion e-mails for a billion
files just because they were heavily outdated (and still need to check
again one of these days since I've not had time for e-mailing them
recently.)
In short, it's easy to say, "No one uses it or no one cares", but
that's a fallacy, you just have to know where to look!! (Feel free to
ask, I have spent some time on this.)
Rod Pemberton
>
> (or is outdated) making it not too useful anymore.
>
Is there any current DOS site not-dedicated to a specific project (e.g., a
version of DOS, a DOS compiler, a DOS graphics library)? Perhaps, DOS
Webring? AFAIK, those were the best of the best...
When I can, I program what I need for DOS. But, these are a few app's I've
been using that I think came from those sites:
486dis_c.zip by Robin Hilliard (and from code by DJ Delorie and Kent
Williams)
- table driven disassembler, C, GPL'd derived from DOS GNU C++ Debugger
- easy to modify, e.g., I've mostly converted it to NASM
- probably not easy to make workable with MMX, SSE instructions
fhard101.zip by Aaron L. Brenner
- driver to emulate a small HD using floppies, assembly, Public Domain
- DOS 16-bit character and block device drivers
- requires binary disassembly work to recreate missing constants and code
from missing includes (dd_def.inc, vhard.inc)
- e.g., I've reworked as a floppy driver - works in Win98SE too
ddl.zip by P. Frost
- command line device driver loader, copyrighted
- like devload, but I prefer it to devload. It has a couple of bugs and
quirks...
- small, easy to disassemble and modify (legal for personal use...)
x2b11.zip
- exe2bin replacement, assembly, Public Domain
- just noticed from one of your links...
Well, first, I haven't thoroughly combed through some of those website,
e.g., like the OS/2 sites. OS/2 users had to have produced some good DOS
stuff in their time that was little known outside the cult-like OS/2
community. That reminds me, I need to search for Amiga C code again...
IIRC, there are also some DOS file collections from other countries, e.g.,
Australia, that I didn't have links for. Or, was that Hobbes?... Second,
I've been collecting C code which is not-copyrighted (Public Domain) and
could be compiled for 32-bits. Many of the packages in these older DOS file
collections are copyrighted without source, or if they weren't, they had
code that was written in 16-bit assembly. While I do code in 16-bit and
32-bit assembly, I'm not that interested in porting from 16-bit assembly to
32-bit assembly as DPMI code to be used on a 16-bit DOS OS... So, for the
most part, I haven't been saving them. IMO, the open source, GPL'd, code
movement that benefitted Linux, bypassed DOS. Most of those DOS collections
had applications which are trivial programs (Sad!), pre-compiled executables
(Good!), usually lacked source (Bad!), shareware (Problematic!),
postcard-ware (Huh!), had copyright restrictions to personal, educational,
non-commercial, non-military, and non-government use, etc (No Big Brother!).
Those last "moral" restrictions aren't allowed in a modern open source
licenses... (Shock! Surprise! No government opposition allowed with
GPL...) Unfortunately, other old file collections - no longer available -
e.g., for DEC VMS, were just *understood* to be "Public Domain", but the
code they had never stated that it wasn't copyrighted by the original
author... (Uncertainty!) Anyway, I've still saved many DOS packages. Some
I've never used or opened. Periodically, I delete some - typically when I
can't figure out why I saved it. Crynwyr was the largest collection of DOS
packet drivers. But, numerous other DOS packet drivers, shims, network code
templates are on those sites. They should still work. So, you could make a
large collection of them. I'd suspect you could also build a large
collection of DOS text editors too. They should still work too. Much of
the other stuff is obsolete or trivial or copyright restricted or in
Pascal... etc.
Also, some stuff still on Ibiblio too:
http://www.ibiblio.org/pub/micro/pc-stuff/
Rod Pemberton
Ste...@aol.com
All groups > Usenet: comp . os . msdos
comp.os.msdos.4dos. (1)
comp.os.msdos.apps. (1)
comp.os.msdos.desqview. (1)
comp.os.msdos.djgpp. (1)
comp.os.msdos.mail-news. (1)
comp.os.msdos.misc. (1)
comp.os.msdos.pcgeos. (1)
comp.os.msdos.programmer. (2)
internetindos
freedos
simtel
timo salmi
Rugxulo
On Mar 19, 7:22 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:4f7b4d8f-fa46-43d0...@v38g2000yqb.googlegroups.com...
>
> > (or is outdated) making it not too useful anymore.
>
> Is there any current DOS site not-dedicated to a specific project (e.g., a
> version of DOS, a DOS compiler, a DOS graphics library)? Perhaps, DOS
> Webring? AFAIK, those were the best of the best...
There are some, yes. For instance, Programmer's Heaven has lots of
files, and Richard Bonner's site has a lot of links:
http://www.programmersheaven.com/
http://www.chebucto.ns.ca/~ak621/DOS/Websites.html
In particular, I meant Simtel is almost frozen in time ever since
Digital River took over. Almost everything there is outdated.
As far as webrings, I don't think those are active anymore. In
particular, I think SET had a good page, but he's apparently long ago
lost interest.
> 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).
And there's an old IDA Pro Freeware version for DOS too (3.7, I
think ... haven't tested 4.5 under HX, too lazy). There are a billion
more, of course. EDIT: NDN has one built-in too.
> 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, but I do know of
some floppy image -> drive emulators (shsufdrv, timage, e0x, etc).
> ddl.zip by P. Frost
> - command line device driver loader, copyrighted
FreeDOS has a good one called devload. And the one DR-DOS uses (by Jim
Kyle) was supposedly from the book _Undocumented DOS_.
> x2b11.zip
> - exe2bin replacement, assembly, Public Domain
Some linkers will do this for you. Also, OpenWatcom has one (FreeDOS
uses it).
> Well, first, I haven't thoroughly combed through some of those website,
> e.g., like the OS/2 sites. OS/2 users had to have produced some good DOS
> stuff in their time that was little known outside the cult-like OS/2
> community.
The problem is that EMX seems to be abandoned for whatever reason. If
it is used, it's OS/2 only, and they don't even bother testing for
DOS. So some things don't work even when they probably could. Not a
huge deal, but still annoying.
What's more annoying is when a new version obsoletes a different (but
still working version) like an older real mode version or compiled by
a certain compiler (since all have strengths and weaknesses, e.g.
OEmacs). In other words, if you want DOS16, OS/2, or Win31 apps, don't
always expect that one doesn't exist just because the latest version
doesn't have it (e.g. Jed). Obviously, though, something compiled by
DJGPP works in all of the above situations, which is a huge advantage.
You can't even get that good compatibility from most Linuxes or
*BSDs !!
> IIRC, there are also some DOS file collections from other countries, e.g.,
> Australia, that I didn't have links for.
Like this (but Austria, not Australia)?
http://gd.tuwien.ac.at/pc/dos/
> Or, was that Hobbes?...
Even Hobbes (which was like a big OS/2 site) is outdated on some stuff
(e.g. not latest RSX, NT09D). And they lack older versions too (e.g.
EMX Emacs 19.27, which supposedly runs with RSHELLWX).
> Second,
> I've been collecting C code which is not-copyrighted (Public Domain) and
> could be compiled for 32-bits.
I assume you know of Bob Stout's snippets page?
> Many of the packages in these older DOS file
> collections are copyrighted without source, or if they weren't, they had
> code that was written in 16-bit assembly. While I do code in 16-bit and
> 32-bit assembly, I'm not that interested in porting from 16-bit assembly to
> 32-bit assembly as DPMI code to be used on a 16-bit DOS OS... So, for the
> most part, I haven't been saving them. IMO, the open source, GPL'd, code
> movement that benefitted Linux, bypassed DOS.
I don't know, it's like some people never even tried to make stuff
work in DOS. I think worse is when it doesn't work on Windows, then
people *really* get mad and run away. And that's become much more
common on modern versions.
> Most of those DOS collections
> had applications which are trivial programs (Sad!), pre-compiled executables
> (Good!), usually lacked source (Bad!), shareware (Problematic!),
> postcard-ware (Huh!), had copyright restrictions to personal, educational,
> non-commercial, non-military, and non-government use, etc (No Big Brother!).
> Those last "moral" restrictions aren't allowed in a modern open source
> licenses... (Shock! Surprise! No government opposition allowed with
> GPL...)
Yes, I know, it was a major source of frustration having such crappy
licenses for DOS apps. Some things (text editor, memory manager,
compiler, assembler, debugger, disassembler, compressor / archiver,
screen saver, defragger, undelete) are almost a necessity, IMHO.
(Well, not a necessity exactly, but you know what I mean.) In some
ways, I think we're all doomed to reinvent to wheel until everybody
finally agrees to "behave" and use *reasonable* compilers and licenses
(and support reasonable compatibility, avoiding NIH syndrome). It's
still a long way to go ....
> Unfortunately, other old file collections - no longer available -
> e.g., for DEC VMS, were just *understood* to be "Public Domain", but the
> code they had never stated that it wasn't copyrighted by the original
> author... (Uncertainty!) Anyway, I've still saved many DOS packages. Some
> I've never used or opened.
I usually test everything I download, but there are some things I save
for the unknown future. In particular, I lose interest pretty quickly
on some little things (probably due to too many projects). It's hard
focusing enough to actually start, much less finish, a project. So
obviously I have some idea how hard it is. :-)
> Periodically, I delete some - typically when I
> can't figure out why I saved it.
Some things I just get so frustrated with that I delete, e.g. when it
doesn't compile easily or requires obscure tools.
> Crynwyr was the largest collection of DOS
> packet drivers. But, numerous other DOS packet drivers, shims, network code
> templates are on those sites. They should still work. So, you could make a
> large collection of them.
I've never understood networking very well, and DOS isn't exactly
friendly in that regard. Besides, I doubt Broadcom works in DOS
anyways. :-/ (Anyways, I've got good ol' Windows + DOSBox + QEMU
+ FreeDOS, which is better than nothing. Oh, and other older
computers. If I ever get off my duff and finish some stuff, I might
actually dual boot FreeDOS, esp. since non-NTVDM emulation is so damn
slow. I'm a fairly determined person, but I cannot stand waiting hours
just to compile something. Of course, most C code never compiles right
out of the box anyways, which is why I sorta almost prefer assembly.
But then you lose a big chunk of available code and still have to
figure out which assembler to use, always having different strengths
and weaknesses.)
> 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
> 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
(or, realistically, sometimes is good enough and sometimes ain't). I
think part of DOS' problem is PR: "Ewww, 16 bits is old and slow."
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.)
> Also, some stuff still on Ibiblio too:http://www.ibiblio.org/pub/micro/pc-stuff/
Yes, FreeDOS mirrors a lot of stuff there. (Hopefully they will still
do so while Jim if off getting his MBA. He was pretty diligent, to say
the least.)
Rod Pemberton
> > 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
Robert Riebisch
> 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).
My FIX8X14 (<http://www.bttr-software/fix8x14/>) is not Public Domain,
but GNU GPL v2.
--
Robert Riebisch
Bitte NUR in der Newsgroup antworten!
Please reply to the Newsgroup ONLY!
Rugxulo
On Mar 20, 3:52 am, Robert Riebisch <Robert.Riebi...@arcor.de> wrote:
> Rod Pemberton wrote:
>
> > 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).
>
> My FIX8X14 (<http://www.bttr-software/fix8x14/>) is not Public Domain,
> but GNU GPL v2.
There are various device drivers (e.g. Japheth's SETMxx) out there.
Heck, FASM comes with one example (although honestly I don't know what
it does, if anything).
As far as simple and public domain, I do know of one that does the
simple ROT13 cypher (but it didn't work with FreeDOS last I checked
due to the kernel erroneously trying to read from it, reported but
still unfixed, obviously not important though):
http://www.programmersheaven.com/download/1441/download.aspx
http://www.mail-archive.com/freedos...@lists.sourceforge.net/msg02040.html
Anyways, Eric Auer has written a few (moresys, sysmem) that include
sources, GPL I think. And Martin S.'s FDXMS stuff exists too
(assembler-with-cpp). And Jack Ellis' drivers too.
Yeah, so there are various examples. Doesn't mean I've ever studied
them too closely, though.
DJ Delorie
> AFAICT, there aren't many DOS .sys device drivers with source.
Here, have another one. It's only 21 years old but should still
useful :-)
I probably have a bunch more kicking around, too, although most of my
utilities were TSRs, not device drivers.
title buf160
; History:216,15
; 09-21-87 12:53:59 rearranged force routine
; 09-16-87 16:07:46 added publics
; 09-16-87 16:01:41 comment out buffer transfer code with equate
; DJ Delorie
;
; masm buf160;
; link buf160;
; exe2bin buf160.exe buf160.sys
;
; DEVICE=buf160.sys ( in config.sys)
;
transfer equ 1
dqq struc
ofs dw ?
seg dw ?
dqq ends
wqq struc
w dw ?
wqq ends
bqq struc
b db ?
bqq ends
rqq struc
len db ?
unit db ?
code db ?
status dw ?
q1 dd ?
q2 dd ?
mdesc db ?
trans dd ?
count dw ?
rqq ends
cseg segment byte
assume cs:cseg,ds:cseg,es:cseg,ss:cseg
org 0
success equ 0100h
error equ 8100h
busy equ 0300h
public header
header label near
dd -1
dw 8000h
dw strat
dw intr
db 'KBUFFER$'
public req
req dd ?
dw 0
buffer_get equ 1ah
buffer_put equ 1ch
buffer_start equ 80h
buffer_end equ 82h
public queue_start,queue_end
queue_start label word
dw 160 dup (0)
queue_end label word
dw 0
public strat
strat proc far
mov cs:[req].ofs,bx
mov cs:[req].seg,es
ret
strat endp
public intr
intr proc far
push ds
push es
push ax
push bx
push cx
push dx
push di
push si
mov ax,cs
mov ds,ax
les bx,cs:req
mov si,offset cmd_table
mov cl,es:[bx].code
mov ch,0
shl cx,1
add si,cx
call [si].w
les bx,cs:req
mov es:[bx].status,ax
pop si
pop di
pop dx
pop cx
pop bx
pop ax
pop es
pop ds
ret
public cmd_table
cmd_table:
dw cmd_init
dw cmd_none
dw cmd_none
dw cmd_none
dw cmd_none
dw cmd_none
dw cmd_none
dw cmd_none
dw cmd_output
dw cmd_output
dw cmd_output_status
dw cmd_none
dw cmd_none
public cmd_none
cmd_none proc near
mov ax,success
ret
cmd_none endp
public cmd_output
cmd_output proc near
mov ax,40h
mov ds,ax
mov cx,es:[bx].count
les bx,es:[bx].trans
output_loop:
mov al,es:[bx]
inc bx
call force
jc output_error
loop output_loop
mov ax,success
ret
output_error:
mov ax,error
ret
cmd_output endp
public force
force proc near
cli
mov di,ds:[buffer_put]
call buf_wrap
cmp di,ds:[buffer_get]
je buffer_full
xchg ds:[buffer_put],di
xor ah,ah
mov ds:[di],ax
clc
sti
ret
buffer_full:
stc
sti
ret
force endp
public buf_wrap
buf_wrap proc near
inc di
inc di
cmp di,ds:[buffer_end]
jne no_wrap
mov di,ds:[buffer_start]
no_wrap:
ret
buf_wrap endp
public cmd_output_status
cmd_output_status proc near
mov ax,40h
mov ds,ax
mov di,ds:[buffer_put]
mov si,ds:[buffer_get]
call buf_wrap
cmp si,di
je buffer_busy
mov ax,success
ret
buffer_busy:
mov ax,busy
ret
cmd_output_status endp
public last_code
last_code label near
public cmd_init
cmd_init proc near
mov ax,cs
mov ds,ax
cmp ax,0ff8h
jbe no_init_error
jmp init_error
no_init_error:
mov cx,40h
mov ds,cx
mov ax,ds:[buffer_start]
cmp ax,0
je incompatible
if transfer
public transfer_buffer
transfer_buffer:
mov si,ds:[buffer_get]
mov di,ds:[buffer_put]
mov bx,0
transfer_loop:
cmp si,di
je transfer_done
mov ax,[si]
mov cs:queue_start[bx],ax
inc si
inc si
inc bx
inc bx
cmp si,ds:[buffer_end]
jne transfer_loop
mov si,ds:[buffer_start]
jmp transfer_loop
public transfer_done
transfer_done:
endif
mov ax,cs
sub ax,cx
shl ax,1
shl ax,1
shl ax,1
shl ax,1
mov cx,ax
add cx,offset queue_start
mov ds:[buffer_start],cx
mov ds:[buffer_get],cx
add cx,bx
mov ds:[buffer_put],cx
add ax,offset queue_end
mov ds:[buffer_end],ax
les bx,cs:[req]
mov es:[bx].trans.ofs,offset last_code
mov es:[bx].trans.seg,cs
push cs
pop ds
mov ah,9
mov dx,offset banner
int 21h
mov ax,success
ret
incompatible:
push cs
pop ds
mov ah,9
mov dx,offset msg_bad
int 21h
mov es:[bx].trans.ofs,0
mov es:[bx].trans.seg,cs
mov ax,success
ret
public init_error
init_error:
mov dx,offset msg_err
mov ah,9
int 21h
mov es:[bx].trans.ofs,0
mov es:[bx].trans.seg,cs
mov ax,success
ret
cmd_init endp
public banner, msg_err
banner db 'Buf160 has been loaded.',13,10,'$'
msg_err db 'Buf160 is not in the first 64K of RAM.',13,10
db 'Please make sure that Buf160 is the first entry in your config.sys file.',13,10,'$'
msg_bad db 'Buf160 is not compatible with this computer.',13,10,'$'
intr endp
cseg ends
end
Rugxulo
On Mar 20, 2:32 pm, DJ Delorie <d...@delorie.com> wrote:
> > AFAICT, there aren't many DOS .sys device drivers with source.
>
> Here, have another one. It's only 21 years old but should still
> useful :-)
>
> I probably have a bunch more kicking around, too, although most of my
> utilities were TSRs, not device drivers.
I actually saw a tweaked version of this (from 1992, slightly updated
by David Kirschbaum, Robert M. Ryan) about a year ago. Obviously the
most surprising things about it were the age and the original
author! :-)
ftp://garbo.uwasa.fi/pc/keyboard/buf160_6.zip
; v1.6a, 2-29-92, Robert M. Ryan
; - Added CLI and STI in installation routine. (hgm)
;
; v1.6, 2-26-92, Robert M. Ryan
; - On conditional assembly of PRIVATESTACK, this program will create
it's
; own stack. This was implemented due to problems on some older PCs.
; - Refine checking of segment boundries, based upon recommendation by
; Harry McGavran (h...@moki.lanl.gov)
; - Added missing a LES before stuffing data into driver header. (also
hgm)
; - Eliminated unnecessary structures and generally cleaned up code.
; - Changed name to BUF160, rather than BUF160_4, BUF160_5, etc.
;
; v1.5 10-23-91 Robert M. Ryan
; - using PUSHA and SHL AX,4 on conditional assembly for 286
; - changed the default buffer status to have TRANSFER enabled, so
that
; keys pressed during initialization are preserved.
; - changed case of es and ds to be like the rest of the registers
; - added initialization of BX so Cmd_Init would work
; - slightly modified initialization message
;
; Rob Ryan, Brown University
; Rober...@brown.edu or 7032...@CompuServe.Com
;
; v1.4 09-26-88 Toad Hall Tweak
; - Donno WHY all the public mess. Leaving it, tho.
; - Donno why author commented out the buffer transfer code.
; I guess, since we're loading as a driver right at system startup,
; there shouldn't BE anything in the old keyboard buffer.
; Driver works fine with TRANSFER enabled (1), but donno what good
it
; does. Therefore leaving the default (and compiled driver) OFF
(0).
; - Changed case: constants UPPERCASE, procedures mixed Upper_Lower,
; variables remain lowercase. (Helps to keep my head straight.)
; - Added some comments.
; - Moved Force inline (since only called once)
; - Using string commands in Transfer_Buffer (lodsw, stosw)
; - Just below Transfer_Done, recoded to use AX when stuffing words
; into variables (faster than old code using CX).