FWIW, one thing to keep in mind is that when Microsoft implemented LFN they
didn't actually do it in DOS. LFN was not implemented until Windows was
started and you were operating in a DOS box underneath Windows. As far as how
MS "integrated" things like caching with LFN & SFN, and what happene
> Does anyone know of a page (or has a file) with a complete listing of
> exitcodes
> for the various DOS commands? (at least MS-DOS) I was unable to find such a
> page, the information seems scattered.
I don't think there is such a list, and I don't even think MS produced such a
list. ErrorL
> extraction the version wanted out of
>
>mov AH, 30h
>int 21h
>cmp ax, ABCD <<< this is the version wanted
>jne exit_program
>
> is not "heuristic". So simple.
>
> It returns exactly the version required to the calling program. if this
> request > is posted in the proper form.
>
> the resident part of SETVER (MS-DOS 6.22) when loaded as a device
> driver is 464 byte on my system. This is mainly the version table
> (4Bh bytes for other stuff like the device header). The SETVER
> device driver notifies the kernel about the location of the table.
> The far pointer to the tabl
> I noticed that there is a minimal SETVER driver implementation [1] in the
> FreeDOS kernel source, and it is shipped with FreeDOS as SETVER.SYS. However,
> there is no accompanying executable in the FreeDOS distribution to modify the
> (empty) list of DOS version assignments for specific executab
I could be completely wrong, but 40:96 (& 40:97) are BIOS data and DOS would
not normally have any direct effect on them. The enhanced keyboard bit should
be set (or not) by the BIOS before DOS (or any OS) even begins to boot. Some
of the bits will change in real-time as keys are being pressed
>> *The storage card is like 2GB and I partitioned mine as about 1.5GB &
>> 500MB—
>> the 500MB D: is where I keep my documents & other files, and install any
>> third
>> party games & apps I want to use. Then whenever I want to install a new
>> FreeDOS,
>> I just wipe the 1.5GB C: partition a
> My only issue is that the OpenWatcom FORTRAN 77 compiler isn't able to
> compile programs on the Pocket386 laptop. But OpenWatcom F77 works
> fine on QEMU, so this is something to do with the Pocket386's 386-SX
> CPU, which doesn't have a math coprocessor.
That could well be the problem, but it
> There reportedly was an issue [2] regarding stack usage with the Open Watcom
> built binaries.
> Skimming over the source, especially [3], indicates that this may use A LOT of
> stack space depending on what value MAXPATH is defined to be (it is 260 for my
> Open Watcom installation). That is ap
> My preference would be the much simpler route and only include
> programs that work on the popular (well known & supported) virtual
> machines and on real hardware. I think the issue is a few games. So
> maybe that means we wouldn't include some games in "1.5" or "2.0" (or
> whatever comes after
> I tried it on my Pocket386 (real hardware) but the game won't start,
> saying it needs a joystick to play. And it's true: I don't have a
> joystick or a mouse connected to this. My joystick and my mice are all
> USB, and this system doesn't recognize the on-board USB port.
I have a never-release
> What we would probably need is a Unix-style NLS system. under Unix you
> would have
>
> LANG=PT_PT.latin1
>
> or
>
> LANG=PT_BR.UTF8
>
> It's not only about messages in programs, but date formats, currencies etc.
That's changing the fundamental way DOS works. You're correct that all those
item
> It is not always just 2 letters. For example, Portuguese is PT and Brazilian
> Portuguese is PTBR.
Two thoughts this brings up. One is that we are not following the ISO
standard. Perhaps not a big deal, but that means we are on our own and will
definitely need to document everything to avoid
be
in English, is the LANG environment variable required to be EN or can it also
be US (or UK or AU or NZ or ...)? That is, can the LANG environment variable
correspond to a country code where the "common" language is the one you want to
use? I know what I think the answer _should_ be (
> That makes me wonder: what is the realistic datarate of a 1,5 MB/sec UHCI
> connection? Is it really 1,5 MB of transferred data or more like 1/3 of that
> (0.5MB/sec) as is the case in USB 2.0?
It is similar to USB 2 in that respect, but USB 1 is even a little less
efficient than USB 2 in some
> Are you sure about the non 512 byte sector support?
> The fake RAM disk that I show when a NetDrive drive letter is not connected
> uses four 64 byte sectors and FreeDOS can read it just fine. FreeDOS Chkdsk
> is
> limited to only working on 512 byte sector devices, but normal reads from the
>
> Yes. With the tiny little difference that we have one broken machine, and no
> broken hypervisors.
Incorrect. We have a case of a _class_ of broken machines (technically, broken
CMS's). The fact that Laaca took the time to isolate the problem on his
machine doesn't mean his machine is the on
> FreeDOS is much more stable then MS-DOS due ot:
> 1) Eric Auer did a nice job flushing files to disk which lowered considerably
> power failure problems
> 2) It is much better then MS-DOS for compatibility with modern machines,
> specialy
> big disks and memory
>
> So I vote for implementing wha
> It seems that I have two possibilities how to fix my problem. The first one
> is to
> create a TSR hooking INT13h.
> Second possibility is to compile my own FreeDOS modification when I could
> modify
> the function FL_LBA_READWRITE inside FLOPPY.ASM.
> This seems to be valid because I am maybe
A couple more data points needed.
Firstly, you say the laptop is fairly new, so I assume it is UEFI and your
"BIOS" (the thing that is providing the INT 13h functionality) is actually a
CSM? IOW, you are not running inside some sort of VM?
Similar question for the USB drives that you say work
Does ZEROFILL work correctly with with disks/media that have sector sizes other
than 512 bytes?
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
> MS-DOS v6 or v7.00 return for all 21.73 functions is actually "AL = 0,
> *CF unchanged*", which is the CP/M style error return for unsupported
> functions. If you take care to pre-init CY (Carry Flag set) before the
> call then these versions of DOS will return AX = 7300h, CY, as they
> will leav
I'm not sure how this should be handled, either with this particular program or
others. But with later versions of DOS (in the Windows 9x era) you can have as
many as 32 drive letters instead of just 26 by putting some like LASTDRIVE=32
in CONFIG.SYS. I don't know if FreeDOS supports that or n
> A couple of corrections...
> ...
>> There is even an EMM286.EXE driver for machines with a 286 CPU floating
>> around
>> the Internet that basically does the same thing EMM386 from MS does
>> (including
>> providing virtualized EMS).
>
> Never seen that one. But the 286 memory managers I saw,
>> this is 2025. Are there really programs *in use* that *require* EMS, and
>> can't
>> use XMS? I'm sure they exist, but are they of any public interest?
>
> 100% yes there are.
>
> Indeed most classic-era DOS apps want and use EMS and very few can use XMS.
>
> Lotus 1-2-3 r2, Wordperfect, SuperC
The mini-boxes are kind of expensive for what you're getting, but might be
worth it for some people. They are physically pretty small, which is nice, but
don't have built-in peripherals like floppy drives, serial/parallel ports,
CD-ROMs, or slots to plug things in. The I/O they do have is prob
> The UPX issue would be irrelevant if we didn't ship binaries at all. Hear
> me out. :)
>
> Repeatedly, I have seen stressed here the importance of making sure all
> packages we ship are 100% open source. And rightfully so - I don't
> disagree with that.
Be careful not to conflate things here --
> VERY unlikely as "race conditions" require multitasking which they don't.
> Btw, "race conditions" usually don't fail reliably, but rather like 10% random
> chance of failure.
Not necessarily. "Race conditions" can really apply anywhere there are
multiple things going on at the same time even
Interesting. Thanks for the research, Eric.
As far as mice and wheels, CTMOUSE is the only driver I know of that allows DOS
programs to use the wheel. This is emulated in DOSBox, but the second wheel is
simply processed as keystrokes because the second wheel is not even an option
with the CTM
> The versions 0.9.4 - 0.9.8 of 8088_bios [1] seem to be affected by a
> bug I described in an GitHub issue [2]. It causes DS:0041 to be
> overwritten by the BIOS. Problem is, that DS points to whatever it
> is set when entering the BIOS and not to the BIOS data area. The bug
> is that the BIOS fai
That solves the problem with commas, but it looks like you may still have
issues if there are quotes in the file.
I know one thing I've done in the past with some of my programs is allow the
use of either a double-quote ("), single-quote ('), or grave-quote (`) as
string demarkers, which allows
> I'm using the "r" (replace) instruction correctly: 1rfrom,to will
> start at line 1 and replace "from" with "to".
>
> But it looks like a leading space is ignored, so edlin treats my
> "1rwritten, written" as just "1rwritten,written" and seems to ignore
> it because the "from" and "to" strings ar
The thing I would do to speak against it is that because none of the other DOS
versions, including older versions of FreeDOS, will be able to use it. I do
know different versions of DOS do the ordering of the drive letters differently.
I think the best thing to do is try to automate it as much
> I would have another question regarding USBDOS' license: what about
> manufacturers that sell computers with FreeDOS preinstalled to avoid
> the Windows tax? For instance in the Middle-East, many local
> manufacturers do that, and even big names like HP because the
> Windows license fee isn't neg
> Hi Bret,
>
> > [..]
>>> I see the point with item 5. However, the mention of a "..directly
>>> from a web site that charges a 'registration fee'.." seems (to me) to
>>> be specific to sites that charge a mandatory fee to access file
This Bret, the author of USBDOS (and a few other programs also. I've added a
few comments below to Jim's comments, but basically Jim is right on target.
People have made comments about how this is a non-standard license and would
like to see me incorporate a widely-published one (and
FWIW, Microsoft's HIMEM.SYS is compatible with 286 CPUs (and also with 386+).
There's also an EMM286.EXE floating around that provides EMS for 286-class
CPUs, but I don't think MS had anything to do with it.
___
Freedos-devel mailing list
Freedos-dev
> The first one I can remember was the Mitsumi CRMC-LU005S single speed
> drive, which was the one I had. It had its own card because it was
> non-IDE despite the fact that the cable and plug looked exactly like
> IDE. They did use a proprietary standard. They definitely worked on an
> 80286, so I
> Yeah, USB and CD/DVD makes only sense for a 386+ ...
USB, yes. CD/DVD, no. USB requires PCI which in turn requires 386+.
Actually, there were supposedly USB host controllers manufactured for the ISA
bus instead of PCI, but I've never actually seen one. But USB protocols assume
you're usin
> So (unless I stuffed the test up), it's not just me that says
> that stdin isn't stdin - Freedos get device info returns 0.
> So freedos reports that stdin is not stdin, and I took its
> word for it in my test of set device info.
I just tested FreeDOS 1.2 and 1.3 and a couple of other versions o
Those extra "spaces" may not really be spaces at all -- they may actually be
ASCII 0 or ASCII 255, which look like a regular space (ASCII 32) on the screen
even though they aren't. I've ran into similar issues at various times that
have caused me all kinds of grief. There are also some DOS Cod
> mov ah, 044h
> mov al, 01h
> mov bx, 0
> ;mov dx, 081h
> mov dx, 0h
> int 021h
> mov ah, 04ch
> int 021h
Looking at this again, I think I see what your problem might be. You have
commented out the "mov dx, 081h" which makes me think you are trying to do
something with a hard drive (which is
Tom is absolutely correct. You are trying to change the attributes of Device 0
(STDIN) to 0 (so that is it is not really even a device any more). After that,
for all practical purposes, you have disabled the computer.
Apparently, FreeDOS doesn't see this as a problem (it assumes you know what
I've used GEM, GEOS, and DOSShell all in the past and they all have quirks and
issues that make them all less than ideal for my use.
DOSShell is a really good idea (it supposedly used the same task-switching
mechanism that was in Windows 3.x), but I found it very clunky to use. It does
work pr
> It seems to me that te question is "Shall a device
> exist in a non-existing directory ?"
I don't think that's the correct question. I think there are two questions.
The first question is, "Does a device exist in a non-existent directory?" The
answer to that is no -- a device does not exist
Rather than merely trying to copy the way MS did/does things regarding IF EXIST
X:NUL, I think we can discuss what the "right" way to handle things should be.
NUL is a device, not a file, though it can sort of look like it is a file in
some circumstances. In at least a sense, any device (NUL or
>> But mostly, I think it would look really cool to have all Zeros in
>> the Conventional Memory Column.
> I think this would be an exercise in futility. After all, there are
> parts of the kernel, which are the first part of (Free)DOS being
> loaded (by the boot code in the MBR) and then are bein
> For fun, I decided to implement a single binary compiler directive.
> When enabled, it generates a single COM that acts as both the driver
> and interface program. But, I am unsure if I will use that or the
> dual (SYS+COM) build for the 1.0 release.
FWIW, in my TSRs I don't try to create a SYS
> Sometimes, I suffer from a severe lack of trust in other
> programmers. I look at the "Install Check" and see only specific
> registers are to be modified and no others are to be destroyed. But
> in my head, I think that someone out there may think it is a good
> idea to save some time by passing
> For fun, I implemented initial versions of both the 0x2b interrupt
> hook and a partial 0x2d implementation to locate the Logger device
> driver.
>
> The 0x2d version is very bare bones and does not include several
> functions required to be fully compliant. It only responds to the
> install che
Why not use AMIS (INT 2Dh)? It's there for the very reason you're proposing.
However, it's much more involved than your simple test, but also provides many,
many additional features and allows simple communication, interaction, and even
cooperation between all TSRs and Device Drivers that supp
> However, the topic of port I/O and MMIO reminds me of some activity
> by RayeR and others regarding low-level configuration to speed up
> access to PCI / PCIe graphics in DOS. I think the issue was that no
> fast defaults were applied by the BIOS, slowing down VESA LFB a lot.
Video is kind of a
>> I tried posting a much longer response to this, but it was
>> apparently rejected by the moderators. Here's a shorter one.
> As I already mentioned in the other reply to this thread, feel free
> to send me more specific replies to that article.
I'm not sure why it didn't get posted -- it got
>>> The article is found at
>>> https://pushbx.org/ecm/dokuwiki
>>> /doku.php?id=blog:pushbx:2023:0321_cpu_performance_comparison
>>
>> I mostly agree with you and your article, but:
>
> fine that you agree, but at most 50% of the article is even close to
> 'right'.
You're the one who said, "I mo
Hi,
am Dienstag, 21. März 2023 um 23:26 schrieben Sie:
> Hello!
The article is found at
> https://pushbx.org/ecm/dokuwiki/doku.php?id=blog:pushbx:2023:0321_cpu_performance_comparison
I mostly agree with you and your article, but:
>> Conclusion
>>
>> CPU-bound benchmarks are much faster on a
> Saying that a Core i7 with the caches all disabled is no quicker than
> a 386 is as absurd as saying "well a Ferrari is no quicker than a
> Model T Ford, and that had a 2.9 litre engine!"
Of course it is, except that real-life testing actually proves it. And my test
was with an i5 instead of a
>> Even though a 350 MHz K6-2 is WAY faster than my 3.3 GHz i5? And
>> again, I know it doesn't make any sense, but it's still true.
>>
>> As far as I can tell, the Emperor has no Clothes.
>
> I'm confused by this. You are claiming that a 350 Mhz K6-2 is "WAY" faster
> than a 3.3 GHz i5? In wha
> Seriously, older machines were faster with self-modifying code, but
> newer ones are much more sensitive and slower. Anything within a
> (roughly) 4 kb radius gets slowed down dramatically. I noticed this,
> years ago, on my old AMD TK53x2 laptop.
The code in SLOWDOWN is not self-modifying (as T
Tom:
Often when you say something on this forum, I am reminded of a stanza from the
Tom Petty song, "Into the Great Wide Open." The stanza is "Rebel Without a
Clue." I'm sure you think the same of me.
>> In fact, the new 3.3 GHz i5 CPU runs about 10 times faster than the
>> 33 MHz 386 did, no
> ...
> By no means is VINFO perfect. In fact, there is a known issue in
> detecting some 486 based machines that I have not got around to
> fixing. Also, there some other things that could be done better.
> But, they are mostly minor issues that I have not found the time or
> motivation to remedy.
> Tom's suggestion of using IDLEHALT is most likely the best solution.
>
> As you suggest, Using IDLEHALT for VM's and FDAPM for real
> hardware on installed systems will be easy to do.
>
> Since such decisions cannot be made automatically during boot in the
> CONFIG at present, probably just swit
> the kernel *should* work with sector sizes != 512 (as MSDOS
> reportedly does), but it simply doesn't. I Think PerditionC tried to
> make this work, and was successful for 256, 512, 1024 and 2048.
> unfortunately he didn't succeed for 4096 (I don't know the reason)
> so the FreeDOS kernel is stuc
> ...
> So four cores? But only one core is running under DOS (albeit at max
> clock speed).
> ...
Several somewhat interesting factoids (specific CPU instructions, levels and
sizes of caches, USB speed, pipelining, ips, etc.) but mostly irrelevant to the
discussion at hand.
> So what instruc
and rather than an essay-length response,
> a better one would be to _come up with better explanations_.
It's Bret, not Brent. And I will attempt a better explanation below.
>> I haven't redefined anything. Individual subroutines may be re-
>> entrant but the entire ker
> A Virtual Machine for the rest of us is something like VMWare, Qemu,
> VirtualBox, etc. - something that simulates a real machine. You
> load a real operating system in it and the operating system
> generally doesn't know or care that it's actually in a simulation.
So "the rest of us" is _every
> That doesn't make sense. A VM is a hardware emulator. It doesn't
> get to choose to relocate the InDOS flag. DOSBox can do whatever
> it wants when it is emulating DOS, but a hardware emulator doesn't
> get to do those things.
>
> What VMs are you seeing this behavior in?
I was wondering if
> After thinking a bit about this, I'm fairly certain that FreeDOS is
> NOT (sufficiantly) SDA compliant.
> ...
>
> some of the problems above might be handled by placing CLI/STI at
> proper locations. some are more difficult.
>
> but I'm pretty certain that FreeDOS hasn't a lot of CLI/STI's
> spr
> There is an existing standard definition for re-entrant code, and
> multiple tools and frameworks support it.
>
> https://en.wikipedia.org/wiki/Reentrancy_(computing)
My terminology is compliant with that definition. A couple of quotes from what
you provided:
"A computer program or subroutine
>> 386MAX supports the Global EMM Import Specification (GEMMIS), which
>> allows Windows 3.x to start in 386 Enhanced mode, even when the EMM
>> manager is loaded. (The documentation in the 386MAX source code
>> seems to refer to it as the "Global Paging Import Spec".)386MAX
>> supports the same I/
> This StackExchange answer (from 11 years ago) seems relevant:
>
> https://stackoverflow.com/questions/1163846/what-is-a-reentrant-
> kernel
>
> Note this comment:
>
> This is pretty much standard for today's desktop operating systems.
Interesting, but that's not the kind of re-entrancy I'm talki
> The BIOS idea (separate, in ROM) was invented by Gary Kildall, right?
Not sure about that, but the concept of a "BIOS" -- a "layer" between the
hardware and the OS itself -- still exists today. The difference is that it's
no longer isolated from the OS. MS used to call it the Hardware Abstra
> duh? have you ANY idea what you are talking about? just a tiny bit?
Yeah, I think I do. Let me just say that the computing world would be a VERY
different place than it is now if Operating Systems (and maybe even BIOS's)
were re-entrant. For one thing, MS probably never would have became the
>> But I was still wondering if anybody has seen it done before since
>> I don't think I've ever seen an actual implementation.
>
> neither did I.
Probably not worth pursuing. But even just the idea of a re-entrant Operating
System (rather than just a re-entrant sub-function) is a pretty interes
I'm wondering if anybody has any experience, or has seen any source code,
related to manipulating the DOS Swappable Data Area (SDA) to make DOS
re-entrant. I working on at least one TSR program right now where I think
something like that might be useful but I've never seen it done before.
The
> I'm not sure if this fdisk can already do that, but additionally it
> would also be very useful if it could align partitions to 4k rather
> than 63 sectors to lower wear on flash drives (SSD, CompactFlash).
You can certainly make a case for aligning things on 4k boundaries on both
modern and ol
> But being MS-DOS 5.0 published when it was, after the quarrel with
> IBM, I can just speculate that if MS-DOS 5.0 needed more
> conventional memory, IFS would have been one of the first things to
> go. Which is a pity, because from those articles one can infer that
> it tried to make mounting fi
>> I don't know of a direct or fool-proof way to detect FAT32 support,
>> but maybe somebody else has come up with something.
>
> I believe DJGPP utils (2.04 beta or newer, e.g. 2.05 current) use
> the naive method of "only assume FAT32 if DOS version is 7". (By
> this I mean "du.exe","df.exe" etc.
> Also I found references on IFSFUNC: in 2Fh (AH=11h), IFSFUNC
> functions seem to be entangled with the network redirector
> functions:
>
> http://www.ctyme.com/intr/int-2f.htm
>
> Apparently, these functions would be made available by IFSFUNC.EXE
> (curiously not provided by kernel itself).
>...
For purposes we're discussing here, I don't think DOSBox (or any of its forks,
including vDOS) is a viable solution.
DOSBox really isn't DOS. It's an environment designed to run certain DOS
applications. A lot of stuff is missing in DOSBox that's needed to make it a
"real enough" DOS to be us
> by the way, the 2 programs are the setup stuff and edlin. hardly
> rocket science.
Even those two "simple" programs would probably be considered "rocket science",
or at least akin to "learning a foreign language", by most students who are
only used to modern technology and web apps. Low-level
FWIW, the one I use is also called TED and is an old utility from PC Magazine.
The executable is only about 3 kB (way smaller than the EDLIN that comes with
MS-DOS) and is a VERY basic text editor with a TUI (it's not a line-oriented
interface like EDLIN so is more intuitive to use). It gets t
> Anyone else have documentation they'd like to suggest? (If you want to
> suggest some docs, reply to this thread BY FRIDAY, DECEMBER 2 and I'll
> send a list to the instructor. He can pick from that.)
>
> Jim
How about the documentation for my PRTSCR program (available for download at
http://br
In general, I find that toggling options are a bad idea. Things just get too
confusing, especially if you have multiple "sources" for the options (like
combinations of internal/compile-time default settings, environment variables,
options entered through a batch file, options entered via a comm
> Don't forget Hampa Hug's PCE - PC Emulator:
> http://www.hampa.ch/pce/pce-ibmpc.html
It turns out that PCE has a custom BIOS so it's pretty easy to detect. I was
thinking it would be set up more like PCem and 86Box which actually use images
of the original ROMs from the original computers way
> Don't forget Hampa Hug's PCE - PC Emulator:
> http://www.hampa.ch/pce/pce-ibmpc.html
I'll experiment with that one too, but it's really hard to detect emulations of
really old hardware. You usually need things like PCI and CPUID to detect
things reliably.
___
> What VPC are we talking about?
> VPC as in Virtual PC?
> The one made by Microsoft?
> I doubt, any version of VPC included FreeDOS, but feel free to prove
> me wrong. :-)
I might have misspoke there -- I thought it was JPC he was talking about (JPC
does come with a version of FreeDOS). Virtual
> It also has a general Emulation detection. But, that rarely detects
> a generic VM.
AFAIK, it's not possible to detect a generic VM, though I think when I get done
with what I'm doing I can come pretty close. In your case, though, it sounds
like you actually need that capability for your VGA
> VirtualBox gives you the chance to have 5 different network cards;
> other virtualizers probably similar.
I would know which Ethernet NIC I have configured in VirtualBox. In VirtualBox
you can also detect the Ethernet card though PCI, but that's not true in every
VM. In addition, just becaus
> Since what you need to know is which Ethernet card is being
> virtualized, perhaps it would be sufficient to simply scan the PCI
> bus to see what class 2 devices reside there?
> ...
> Of course, if the majority of cards for which you need to search are
> non-PCI (e.g. some old ISA stuff) then th
> Jerome's V8Power Tools will detect some VMs, IIRC:
Yes, I checked that out. In the version I looked at, it detects 3 different
VMs all using the same method (looking for a specific identification string in
BIOS memory). That method works with some VMs, but not all.
> Although I never truly
> RHV is based on oVirt which is based on KVM plus qemu & libvirt &
> lots of other bits. It'll run DOS but you might have jump through
> hoops (learn virsh and other tools) to get it installed.
>
> BHyve, at least as in TrueNAS Core and OSX/Mac OS before M1 will
> also run DOS.
>
> I think it's at
> But if a game is known to *not* work at all on VirtualBox (for
> example) I recommend we discuss removing it.
This brings up a slightly different topic, so maybe deserves its own thread,
but I'll bring it up here.
I've been working on some updates to the ISLOADED program I sent to Jim a few
w
>> For example, I know it's a big deal these days for musicians to
>> claim that somebody who disagrees with their politics can't play
>> their songs (at things like political rallies). Basically, they're
>> declaring who can and can't listen to their music.
> It's not who can or can't listen, bu
I'll try to search for an appropriate license and e-mail it to you. I've been
searching though a little bit of licensing info and really didn't know that
even declaring that something is "public domain" doesn't necessarily mean what
you think it means. I suspect it may ultimately have somethin
I don't use SourceForge or GitHib or anything like that. The source is in A86
(actually, A386 since there some Pentium-specific instructions). One of the
things I was going to do before releasing it was to convert it to NASM. That
takes quite a bit of work and time that I don't have right now
I have a program but have never officially released called ISLOADED which I can
upload/email to whoever wants to use/see it (including the source code). It
tests for lots of things like video, serial/parallel ports, ANSI,
DPMI/DPMS/VCPI, mouse driver, character device drivers (by name), etc.
>> But IIRC, the common way to check for the presence of an ANSI
>> device driver was to check via an INT 2Fh (multiplexer) call (don't
>> recall the exact call value (AX/AH)).
...
> I remember when Eric Auer added it to NANSI, so it should support
> it:
>
> * https://docs.huihoo.com/help-pc/int-
FWIW, here's the code I use to test whether or not ANSI.SYS is loaded.
;---
;Strings need to test for ANSI.SYS
;---
TestMsg:
DB CR ;String to test A
> Stack allocation could be implicit. Don't know how NASM is handling
> this, as I wouldn't touch that one with a barge pole... ;-)
> Check the list file when assembling this..
In TSR's, the stack is NEVER implicit. It is something you must explicitly
handle somewhere in the TSR. For all but th
For TSR's, there are additional things you can do to reduce memory. You can
look at the source code for my PRTSCR program (available at
http://bretjohnson.us) that uses a BUNCH of tricks. For example, it doesn't
even use the DOS TSR interrupt.
The way it works is to make a "copy" of itself at
1 - 100 of 206 matches
Mail list logo
