> 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 files.
>>
>> That is correct. Voluntary donations to a website owner
;
> I don't know if Bret still subscribes to the freedos-devel list, but
> maybe he is and can answer more definitely. :-)
>
>
> I downloaded a copy of the USBDOS files from https://bretjohnson.us/
> and evaluated that. In USBINTRO.DOC, I found the "COPYRIGHTED
> FREEWARE"
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
>> My terminology is compliant with that definition.
>
> *Sigh*
>
> I am aware of that. The general term "re-entrancy" is not synonymous
> with the specific term "reentrant kernel".
So re-entrancy is not synonymous with re-entrancy? Or the definition of
re-entrancy when applied to a kernel is di
> 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
REMIND seems to be a DOS command-line utility and not a TSR. I'm just
wondering how you would actually use it.
E.g., would you need to run it once a day (in the morning) to print you a list
of everything to do that day, or permanently leave it running in a VM/Window of
some sort that would bee
For me, the thing I usually do is look for one particular utility program to
download (e.g., the latest version of SWSUBST or KEYB or something like that).
I'm not looking to install FreeDOS as a whole.
Finding out where/how to do that is complicated and confusing. In your
usability personas,
> The question is, how should I modify the handler to support sharing
> the IRQ? Is it enough to simply always chain to the "downlink" [4]
> after processing of my interrupt source is done?
I've found that there is no such thing as an, "If you always do it this way
you'll never have any problems"
> Why would ACPI somehow have to be less powerful than the rest of the
> computer firmware?
ACPI is not actually firmware -- ACPI doesn't actually DO anything like
firmware does. Firmware is sort of like "permanent software" (executable code
stored usually in non-volatile RAM or ROM), while ACP
> Modern motherboards use this "Standby" power to run small always-on
> power management circuitry (I believe this is integrated directly
> into the chipset these days) which monitors all sources of a "power
> on" signal, be it the power button on the case, or a LAN controller,
> or a built-in watc
> there is absolutely nothing complicated to have a
>
> "on power return, boot computer"
>
> option. it used to be the default.
You all are missing the point. As soon as the motherboard gets power, it
starts booting. That is how it has always worked.
The problem is how to get the appropriate p
> Is there a way via the ACPI\s API to tell ACPI to automatically power
> on after power loss AND when the BIOS SETUP does not include such
> setting?
The short answer is no, that is not possible.
The long answer is that what you're talking about really has nothing to do with
ACPI and rather has
Technically, REM is a regular DOS command just like the others -- it's not a
"comment" like we're used to seeing in most coding languages. If you type
"REM" at a command line it doesn't give you a "Bad Command" error message
because it is a legitimate command even though it doesn't really do an
I realize that VMs are all the rage these days for DOS, but I would also like
to see how things work on real hardware. I rarely play games myself any more,
but games are usually a pretty good test of compatibility.
The problem is that with real hardware there is WAY more variation than there
i
>> users will have FAR more than 60 GB disk size and you can
>> have only 24 drive letters from C: to Z:
> Up to 32 under some DOS/Windows versions:
> https://en.wikipedia.org/wiki/Drive_letter_assignment#Common_assignments
While you CAN have up to 32 drive letters, it's usually not a good idea t
So, it sounds like Eric would suggest just sticking with two-letter language
codes for LANG, use LANG if it exists (without any verification testing), and
maybe have a command-line override switch?
___
Freedos-devel mailing list
Freedos-devel@lists.so
I've been working with Thraex on the translations of my PRTSCR program to
French and Turkish. I want to thank Thraex for volunteering, and am still
working through the technical details on implementation. I've ran into a few
items that I would like some opinions on how to handle them. These h
> you can design APIs all day long, but if nobody is using these APIs
> it's a bit pointless. and the BIOS certainly will not suddenly call
> any DMA reservation API.
These APIs will be used by anybody who needs to virtualize things like IRQs,
I/O ports, and DMA channels.
> besides this, MSDOS a
> however if several applications want to access the same DMA controller
> at the sam time things get complicated. there is no communication
> between these applications.
Exactly. That's what the API would somehow need to manage. I'm thinking a
program would somehow need to register as the "own
> RBIL sort of implies that all sizes should work, but dword is broken
> and the byte/word distinction is only partially explained in RBIL?
In my actual testing, the only thing that works properly is Bytes.
> Have you seen apps which make use of the QPI way, apart from
> SoftMPU?
No, I haven'
I've been working on adding an implementation of I/O port trapping to JEMM
using the EMM386/QEMM API (INT 2F.4A15). I have it basically working.
I want to clear up some misconceptions, though. As far as the I/O port
trapping, MS did a really crummy job of implementing it. Bob Smith of Qualit
> really? Like in 'Could you provide the German resources?'
> if true, I have done that wrong for the last 50 years.
> Insights from native english/american (English/American) people?
In English, proper names (including things like languages and countries) are
almost always capitalized. I can't
> 248 is the degree symbol on every codepage referenced in the MS-DOS 5> manual
> on my bookshelf: 437 (English), 850 (Multilingual - Latin I),
> 852 (Slavic - Latin II), 860 (Portugal), 863 (Canadian-French), 865
> (Nordic) It would take me a while to research again, but I identified
> several
Jim: A couple of questions & comments on this. First of all, you say that this
is intended to put ASCII codes into a file, but it just writes them to the
screen. You indicate the user was asking how to inject them into a file. The
most obvious way I can see to do that (though certainly not the
We're getting off topic here, but it's worth having a discussion anyway. > in
that case you should translate the documentation first to something> people
might read. people might read 4 or 6 pages. 60+ pages is simply> insane and
exactly nobody will read beyond page 3. Well, I think all I can
You're obviously more familiar with what happens with non-English users than I
am, so we'll use your recommendations and not worry about option-letters or
documentation, at least for now. But I will still need to decide on how to
compile and distribute things (separate executables, a single exe
> DOS programs with source code? They include a free software
> license (as > in freedom)? You have your translator for
> French and Turkish. I can do the l10n if you do the i18n
> part :-)
Well, thanks for volunteering, but what I actually have in mind may be far more
than you're willing to co
> any idea how reliable/wide distributed this is?
It seems to be fairly widely distributed. I just tested in a few places. It's
present in an old HP laptop (I think it's about 7 years old now). It's also
present in VMWare Player and QEMU, but not in DOSBox-X.
I also have it implemented in my
> there is no INT 13nwith a large (32 bit) address. INT 13 can actually handle
> 64-bit addresses, both for LBA sector numbers and memory addresses. Refer to
> INT 13.4x in RBIL. From DOS, though, you probably wouldn't want to use
> 64-bit flat memory addresses, but 64-bit LBA numbers are fine
I saw Wilhelm's earlier comment and started thinking about some of its
implications: i) NLS support: Is there anybody who can tell me if all DOS
commands support [J(a)|Nein] or [O(ui)|N(on)] etc. instead of [Y(es)|N(o)]? If
not, they should do it. As a translator you never know what to do. Sup
I personally use MAPMEM (from the old TSRCOM35 utilities) instead of MEM from
either MS or FD. I find its output much more useful and informative, at least
for my purposes. Here's an example of the output from my current VMWare
virtual machine (running MS-DOS rather than FreeDOS, and loading s
> Adopting GUID of "Microsoft BASIC Data" probably means that boot
> loaders will either show it as "Windows" or try to figure out by
> themselves which version of Windows this is... it could take them a
> while to discover that this is not really Windows, because you said
> it was "Windows" when
1 - 100 of 177 matches
Mail list logo
