I meant that support for controlling PRTSCR in this way could be a part of
the PRTSCR program, without requiring the detour via SCANCODE.
Regards,
Christian
--
EditLive Enterprise is the world's most technically advance
> Indeed. Another interesting thing, though, is that in combination with
> my SCANCODE utility, it is actually possible to "automate" PRTSCR.
Points for creativity, but you have to admit that actual support for
command-line (or environment variable, script) driven operation of PRTSCR
would
>> Now that mTCP is Free Software, I think the next version of FreeDOS
>> should focus on getting basic networking abilities.
> Well, relatively free. A certain group of people are aghast that I used
> GPL v3 - apparently that is not free enough for them. I'm getting a
> good laugh out of that c
> You can also
> run "JEMM386 LOAD" at any time but that doesn't give you UMBs.
A program modifying DOS's internal data which could effectively link in
new UMBs is easy enough to write, provided that the kernel's handling of
the UMA is compatible enough to that of the MS-DOS kernel.
Regards,
Hi Eric,
> As far as I remember, the DOS findfirst API is supposed to find
> character devices (such as NUL) in any (existing) directory, so
> this would depend more on DOS than on COMMAND, but I am not sure.
Without any further investigation, I'd say that's part of it. However,
aside from the
Hey,
> if not exist mydir/nul md mydir
>
> Doesn't work on XP (I think?), but that's the typical "DOS" way.
This kept bothering me for some reason, so I checked now.
It appears to work just fine on MSW NT command lines, executing the
command after "if not exist dir\nul" if and only if that dir
On Sun, 05 Dec 2010 14:13:15 +0100, Fabrizio Gennari wrote:
> Il 05/12/2010 13:25, Fabrizio Gennari ha scritto:
>> Where do I download the new kernel and the new SYS? I guess that, after
>> the download, it's a matter of unzipping in the right folder...
> Found the answer to that:
> http://ftp.g
> http://fd-doc.sourceforge.net/faq/cgi-bin/viewfaq.cgi?faq=General_Information/225
> says obscurely "a little tweaking (of the boot sector "linear partition
> position" / hidden sectors value) should make LBA booting on any drive
> letter possible", but it does not specify what to tweak and how.
> Oh, I thought that the liveCD would do something like look somewhere on
> the
> C: drive for a specific autoexec file and then execute that if it's
> present. I just assumed that it would have that capability. I can't say
> that I understand why it doesn't do this, but obviously there must be
> How do I compile 16-bit-only DOS software from command line?
Try the wcl command. I think "wcl foo.c" should already produce a program
(foo.exe) from the given source file; otherwise read its help until you
get it working. wcl stands for "Watcom Compile & Link", it is a front-end
program t
Seems like it's related to some new hardware stuff that broke floppy DMA.
On some boards Linux is said to have similar problems.
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson,
Hi Bret & list,
I found the problem. Both TESTPASS and TESTFAIL failed in my test
environment, but that doesn't matter. The kernel does not correctly
allocate MCBs for its configuration and initialization program code. The
code that an application loaded by INSTALL= returns to via terminatio
> The TSR I'm working on can't be published just yet, so that's not an
> option right now.
I thought so.
> It's also _really_ complicated, so I'm not sure anyone would want to
> mess with it anyway.
You know me.
> I'm using an older version of the kernel -- I'm not sure exactly which
> on
> Maybe JEMMEX has problems with fragmented memory, did you try JEMM386?
Maybe not..? The issue does not appear to be related to JEMM (as usual).
> The error itself does not tell much - GPF at a 64k segment boundary...
> Could mean that code jumped into an empty segment and fell of its end.
It w
Hi Bret,
I checked the system's state with INSTALL=DEBUG.COM on a boot disk
(Rugxulo's bare DOS disk, with a 2008-03-08 kernel, build 2038) and it
appears fine to me. Memory that belongs to the
configuration/initialization program is allocated to a PSP at segment 60h
(!) which is properly
> That would suggest that you got some of the syntax or maybe order of
> loading things wrong - Can you try if it works with another kernel
> or other keyb versions?
If it crashes, it's a bug, even if the wrong loading order or syntax was
used.
> Maybe problems are limited to some versions.
Ye
(Freedos-devel much?)
Hi,
> It uses kernel 2039 and COUNTRY.SYS, and it more or less works ...
> except for KEYB. For some reason, every computer I try, every memory
> manager, even disabling certain things (CTmouse), it *always* dumps an
> exception when trying to load KEYB. In fact, KEYB never
(Shouldn't this rather go to Freedos-devel?)
> Path 'C:\salami\src\fdos\mem\branches\mem14\...' is not in the working
> copyPath
>
> Anyone getting a similar error?
No, I did not previously read about such an error.
It might be helpful if you would rely more information to the list. Like,
what
>> I keep LBA disabled, for I partitioned the HD with
>> 4-sector clusters.
>
> Clusters and LBA have nothing directly in common. Partitions are made up
> only
> of sectors. It's only subsequent formatting that gives birth to logical
> clusters, after the act of partitioning is over. LBA is about
> Sorry to sound dense but how do you change the kernel from 16 to 32 bits?
>
> Isn't there just one kernel and it works with a filesystem that is FAT16
> or FAT32? Or are these
> kernels compiled with different memory models?
There's one kernel that supports the FAT12, FAT16 and FAT32 file sy
> Some older machines
> (e.g. this) require an specific cluster size in order
> to use LBA.
The BIOS doesn't know anything about cluster sizes. Maybe you mean sector
sizes? Almost all floppy and hard disks have a sector size of 512 byte.
Expect problems with hardware, firmware and/or software
> - Remove the word "DOS" from the name (the thing is unable to boot
> into a PC, so it's not a OS and thus not a DOS)
I don't think they use the term for it, sorry for confusing you.
> - Remove the "DOS-like interface that maps the native file system"
> (so turn it into a clean 80386 / 80486 / e
> Dosbox [...] goes one step beyond in that
> they added to the emulator a DOS-like interface that maps the native file
> system into the DOS system calls, as well as the remaining DOS and BIOS
> system calls.
I might add that I would not generally recommend using the DOSBox built-in
DOS for any
> I use a DOS USB Drivers from bretjohnson.us, someone here ever suggest
> this driver before on this list. However, I'm not familiar with this,
> I took steps and installed the driver but system will hang or tell me
> wrong IRQ. So could anyone show me an example to setup this driver?
Please spec
> Seems you're not old enough to ever have worked with one of the 5V
> Pentium CPUs (60/66MHz) for example... LOL
I didn't really care at the time. I can assure you the AMD K-4 (~ 300 MHz)
and Pentium II (~ 250 MHz) boards that I still regularly use do profit
from idling too. But really, thou
> Apparently, in the Windows partition there is an emulator.
This direction does not get you anywhere, because the emulator's output is
simply the Windows driver for your sound card.
> MPXPLAY is working great for music on FreeDOS, so the sound
> capabilities are there.
This is better. Now lea
> I did not observe such overheating.
That was probably because the CPUs at that time had no consumption high
enough that continuous polling was a problem.
> What if anything has changed since that time?
Are you referring to libraries, the CPU or something entirely else with
this question?
All versions of DOS I know require the use of a TSR (like FDAPM, or
MS-DOS's POWER) to idle correctly, or of a program that does the idling
itself (I don't know any COMMAND.COM version that does so). However, as
the flawed call usually will simply be called by idle-unaware software, an
idle
> What happened was, I had stopped using FDAPM with the portables
> after finding that it was interfering with Bret Johnson's USB
> keyboard driver. Hence the overheating.
Did you report that to Bret already?
Regards,
Christian
> This is just the opposite of what I expected. I always thought
> that it is easier for a processor to run DOS than Windows.
In case you care about the technical background: DOS is dumb. When waiting
for user input, it (all DOS versions I know) by default just loops forever
until a key was pr
> 2. Why do FreeDOS CHKDSK and DEFRAG (as well as MS-SCANDISK)
> report so many errors while DOSFSCK does not, and in practice the
> disks seem to work well?
CHKDSK and DEFRAG ain't that reliable really. Regarding SCANDISK, maybe
you used an old version (MS-DOS 6.x) on a hard disk that's address
> Could you tell me how do I modify this file?
You have to save the JEMM386.EXE file somewhere on the image, then replace
"C:\FDOS\BIN\EMMM386.EXE" in both lines it appears in with the path to and
file name of JEMM386.EXE. The options (behind the EMM386.EXE path) should
work with JEMM just a
> Is there any good USB drivers for USB mass storage like USB flash
> disk? I hope the driver can support USB 2.0.
There's currently two drivers under development:
Georg Potthast's DOSUSB supports UHCI, OHCI (USB 1.x) and EHCI (USB 2.0)
controllers and comes with some drivers (e.g. a disk drive
> Has anyone used any of them in DOS?
Yes. That is, I heard of people using them successfully. But I believe
"Yes" is an adequate answer to your question.
Regards,
Christian
--
This SF.net email is sponsored by
Make
> And check your compiler's docs for what kind of graphics are supported...
I.e. check your libraries. Or get some graphics libraries for DOS or DPMI.
Regards,
Christian
--
This SF.net email is sponsored by
Make an app
> Has any FreeDOS user ever dualbooted with Knoppix (DSL)?
No.
Regards,
Christian Masloch
PS.: If using GRUB, instruct it to boot the FAT partition on which you
installed FreeDOS. Or create a boot sector file of the DOS FAT partition
with FreeDOS SYS then boot t
> - a boot block (MBR) containing a valid description of the FS (number and
> size of FAT[s], CHS geometry, etc. - not all of which can be tuned
> using standard tools probably) - "BIOS Parameter Block" is what
> you want to look for (and compare against actual values in a
>
Hi Stefan,
> My question is not exactly FreeDos related but I hope that you could
> help me anyway:
>
> For an embedded project I need to create a very small FAT12 partition.
> In a proprietary project I found a partition of 4KB size (which I can
> not reuse because of license issues) but could no
>>> PS: for what I know vfat in Linux is just the name of FAT32 ;)
>> Then Linux is not correct, because VFAT is just an extension to FAT12 /
>> FAT16 / FAT32 to allow long filenames:
>
> Ok, but most people should be aware that in the Linux literature (most
> google tutorials) the tem vfat is used
> First of all, what is AHCI? isn't that related to USB???
No. USB is related to the UHCI (USB 1.0), OHCI (USB 1.1), EHCI (USB 2.0),
WHCI (Wireless USB) and XHCI (USB 3.0). AHCI is an interface for SATA
controllers.
Regards,
Christian
-
> Can anyone explain what IDLEHALT=1 does? It could be interesting to know
> this in more details for fure problems or even for general kowledge...
IDLEHALT=1 halts the CPU (with a HLT instruction) before calling Int28,
when the kernel is waiting for a key to be pressed. FreeDOS's default
Int2
Hi Laaca,
please consider registering yourself to the user list as well if you want
to further discuss this or other issues there.
The first issue probably arises from an incorrect check for LFN functions,
or one DOSLFN doesn't support. (Does it work correctly in a Windows 4 DOS
box?) The s
> BTWW, King Udo (EDR-DOS maintainer) reportedly uses it and is happy
> (the only one user ???), possibly the problems occur with FreeDOS
> only, not with EDR-DOS. No idea why and no ambition to debug this type
> of problem :-|
I'm using it too on MS-DOS (for both read and write access) and it did
> There is a simple int21h AH=33h AL=FFh call you can make (no program I
> know of off hand that does it but from debug you should be able to get
> it easy) to get a pointer to the version string displayed at boot.
>
> Something like (completely untested, possibly simpler ways) this in
> debug:
>
> 1) When the CONFIG.SYS menu comes up, no matter how many options the
> menu has, I can only access the first three. I can move up and down with
> the arrow keys, but I can go no further down that to the third option.
> This happened from the moment I first installed it, with the default
>
Hi Jerry,
> After "installing" FreeDOS on a FAT-32 partition, I attempted to boot it
> in a couple of ways, each of which resulted in the message:
> Error loading OS
> immediately after all the BIOS blather.
This message possibly isn't displayed by FreeDOS boot code. I think
neither FreeDOS
>> Floppies are definitely NOT the most reliable DOS boot media. After
>> a year or so of daily use, they will likely become unusable. So
>> unless they keep a ready supply of spares, you're going to have some
>> upset clients. I would go the cd-rom or HD route, because USB drives
>> stick out and
> I just tried sending two versions to Pat, one the suspect tarball, the
> other
> an 'rar' type file; the gmail accepted the rar but rejected the tarball,
> saying;
> "this file contains an executable and is not allowed"; both the rar and
> the
> tarball contain executables? they both have the
Hi,
> Thanks for your interest.
Thanks for reporting to the list!
> One exception is DOSLFN, which I occasionally used in
> combination with the file managers NDN or File Wizard to
> decompress files with InfoZip.
>
> Whenever DOSLFN was used, CHKDSK would find dozens or even
> hundreds of damag
> And speaking of disk checking, I haven't had much luck with DOSFSCK
> either, and still less with CHKDSK. Both crashed with loss of files in
> different occasions. As a result I'm now wary of using either, and
> when I occasionally do run DOSFSCK I get apprehensive.
DOSFSCK works fine for me. I'
> neither as any
> sort of insulting "joke", nor otherwise!
You found that joke insulting? If that's the case, I'm sorry. It wasn't
meant as attack, neither against you nor your software nor anyone at all.
>> If you meant "DOS read" as
>> reading a single or some sectors from a block device, th
>>> I have never seen a RAMdisk that was not file-based
>>
>> Maybe we have a misunderstanding here.. The driver itself
>> is of course a file, but the disk is a DOS block device,
>> so for DOS it is just a bunch of sectors. The DOS kernel
>> will then use those sectors as a FAT filesystem which ca
>>> so it is good that HIMEMX and JEMM386 are still separately available.
>
>> Separately from what?
>
> Separately from MS-DOS, FreeDOS, or other DOS variants, since few if-any
> of their EMM drivers are still under maintenance, and as some have never
> corrected BUGS!
I support your intention (
> JEMMEX could use big pages or
> PAE or both to access more RAM for various things, but this
> always leads to the question: How compatible will it be? At
> the moment, JEMMEX already is too fancy for many ancient DOS
> games which use pre-VCPI DOS extenders,
I think any protected-mode memory man
> I have simply stated our position.
I thought you wanted to discuss it since you even opened up a new thread
for it.
Regards,
Christian
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
t
> With respects to DOS-C, if loading non GPL drivers really did violate
> GPL, then it would have never been released under GPL.
The GPL's text is huge and complicated, if you weren't aware of a
violation you might have released program X under GPL though it actually
violated the license someh
> As far as I can tell, the last commit in the SVN for the project was in
> 2007, so it's either abandoned, in hiatus, or going so slowly that no
> commits have been pushed through in the last two years.
I contacted Salvo a year or so ago and he said there's still work on a new
version which wil
>>> Well, 17 lines of Assembly and 5000 of C,
>> It would interest me where he stated these numbers.
>
> He did not. I just did unzip -p the-sources.zip *.a* | wc :-)
So you don't know how many of that 17 lines are commentary only or
blank. This is something I'm interested in, so I wrote
> > Finally someone did the job: Code USB programs with assembly language.
>
> Well, 17 lines of Assembly and 5000 of C,
It would interest me where he stated these numbers.
> who will ever be
> able to understand and update that code?
Who will ever be able to understand and update Georg's ho
> Decided to try the minimum functionality of HX; the 'stubit.exe' failed,
> complaining that the djgpp executable being
> processed was not PE; I believe that a dj exe always has an 'MZ' stub,
> and I
> will verify that. Does this mean that
> stubit only *checks* the validity of a PE stub and do
> Does anyone know if theres an opposite of subst? (i.e. link a drive to a
> directory) similar to an NTFS Junction Point?
>
> I'm wondering both if there is a driver or maybe a user-land utility
> that can be
> ran to produce such functionality on FAT12/16/32 file systems either for
> use on
>>> Users apparently don't want
>>> technical details on the Freedos-user list however.
>
>> I don't think so: some want, some do not. The question is that
>> currently there's no way to know about it. So I am almost decided to
>> create that freedos-basic list, so that technical details can run he
> Norton Text Search (ts.exe) prints about four characters a second when
> FDAPM APMDOS is running. Setting FDAPM APMOFF fixes this. This may
> also affect other Norton Utilities.
>
> I suspect it's because FDAPM hooks an interrupt for power saving use
> that Norton was already using for so
> First non-bug: LFN-EN utilities don't work with my FAT32 partition
> under FreeDOS.
>
> After examining the source code, it turns out that the logic was coded
> in 1999 when
> the only DOS that could handle FAT32 was MS-DOS. When run under
> FreeDOS, the utilities
> assume no FAT32 suppor
>> Anyone these days using UHCI?
>
> Yes. PCs are randomly distributed as UHCI and OHCI, acording to chip-set
> manufacturer.
Plus, EHCI (for USB 2.0) coexists with UHCI/OHCI. Older USB drivers
usually work with USB 2.0 hardware as well, just not as fast.
Regards,
Christian
---
>> DEVICE=C:\DEVS\RDOSUMB.COM #19 *
>> DEVICEHIGH=C:\DEVS\JEMMEX.EXE A20METHOD:FAST FRAME=E000 VERBOSE NOE801
>> NOE820 NORAM D=0 VCPI
>> DOS=UMB,HIGH
>> DEVICEHIGH=C:\DEVS\EMSDSK.EXE 4364 /c02
> ...
>> 6 file(s)101,406 bytes
>> 0 dir(s) 325,632 bytes free
>> No
>> I haven't tested, but actually *used* these.
>
> Several 100's PC's in 20 years ? Hope at least one was from 1990 and
> also worked :-)
Of course PCs from 1990 don't support USB.
>> How do you know? From your probably buggy 6 PCs?
>
> So I should throw them all away and buy 1 or 6 new ones ?
>
> and - BTW - FreeDOS does NOT want to be a Windows 9x replacement.
Of course not. It wants to be a MS-DOS replacement. The initial question
wasn't to transform FreeDOS into a GUI magically but to create a new
project for a GUI running on FreeDOS.
-
>> development has been to at least support the
>> versions of Windows that ran on top of dos.
>
> This violates the GPL.
That sounds interesting. Completely implausible, but interesting. In what
way does it violate the GPL?
--
>>> Adding block-device support would take a LOT more code
>
> A ramdisk is often a tiny driver. To give block device access
> to UIDE disks,
Okay..
> you only need a partition table parser
Yes, which would reside in the temporary (discarded) part of the driver.
Of course that won't decrease i
>> What are you talking about? ReactOS is not about Windows Me
>
> The request of M.R. (NO, I don't understand it well ... or at all)
Yes, it seems you don't understand it, or at least not the same way I do.
I don't see where he mentioned Windows Me at all.
>> And Windows 3.x/9x is no DOS GUI f
> probably (correct me if I'm wrong) even more
> challenging than writing a dos kernel.
I think you're right on that. For example, Japheth writes on his site that
"HX's source code is about 100,000 lines of code", whereas the current
RxDOS kernel Assembly source code is only around 35,000 line
>> I try to ask what is going to get done in the next release or when XYZ
>> is
>> going to get fixed and I get attacked.
>
> YES, but is cloning of Windaube ME on-topic here at all ? :-D
What are you talking about? ReactOS is not about Windows Me at all,
because Windows Me is effectively part
> HX DOS Extender does support VERY basic Win32 applications, but it is
> somewhat of a hodgepodge. It's basically using the Windows NT form of
> Win32
> as its base. If that could be refitted to work with Wine DLLs then it
> would
> make a lot of the work needed go by a lot faster.
>
> Then we
> There is no reason for an MSDOS Windows replacement to be MSDOS
> compatible.
Except to run on MS-DOS as well. As said, it's Microsoft's method to write
programs such that they only run with other Microsoft programs although
there's no good reason why they shouldn't run with other vendor's p
>> Theoretically, freedos could support an open source replacement.
>
> And in my opinion, the only involvement FreeDOS should have is to
> ensure that any such open source project would have access to whatever
> they need to run, just like any other DOS application. That is, it
> should be a separ
>>> [...] would add a great deal of usability to dos apps, especially
>>> ones that already work directly with sb compatible cards.
> You talk about old apps that make hardware calls. Also would be
> interesting a standar sound library for new DOS apps.
Yes, I talked about old apps, replying to
> Linux has supported ac97 soundcards for years, why can't dos have
> a .sys driver that can be loaded at boot time to do the same thing?
> there's a *lot* of motherboards that have ac97 support these days,
> well over 50%, and having a .sys driver to handle these kinds of
> boards would add a grea
> Now JAM loads but takes ca 32kB of RAM, wow.
According to the documentation that's "Minimum!" ;-) (Your drive
apparently uses 8 KiB clusters. With 4 KiB clusters or smaller, JAM uses
"just" 24 KiB.)
> The FAT32 problem is that JMOUNT needs the raw location
> of the diskimage file represente
> The JAM.SYS driver now passes the OEM number check, but it always hung
> my VMware session. Maybe you have better luck.
There's probably more to it. JAM doesn't know about FAT32, and if I recall
the documentation correctly, it apparently accesses low-level DOS
structures (DPBs) and devices d
> OK, sorry. I thought 2038 was the unstable branch. It is mentioned in
> the wiki about the unstable branch but is denoted stable.
Apparently it's a bit confusing. 2036 was the original build, later
renamed "Stable". From this, the 37 build was created, called "Unstable".
Both of these were
>>> If you're waiting for further improvements to 2038 before you release
>>> 2038, then you're doing this wrong. [...] I'd strongly recommend
>>> making 2038 available, and putting the "few pending improvements" in
>>> 2039.
>> The problem is that Eric holds back at least three necessary patches,
>> This is a question originally sent on
>> a spanish list about BASIC, but
>> is more a DOS question, so I translate here...
>>
>> Writing a DOS app on qbasic or quickbasic to check the disk
>> units on
>> the PC (floppy, HD, CD...) Can check to first CD
>> unit, later if exist
>> a ramdisk how t
> I was reading the Undocumented Dos book and according to it Win 3.x goes
> to extraordinary lengths to insure that the operating system it is
> running on os MSDos and not one of the alternatives.
Yes, but note that the described "AARD" code is not really used in any
retail release (UDOS 2nd E
>> Simple: If you only use WIN /S then you can use the
>> stable 2036 or stable 2038 kernel. The latter is on
>> http://rugxulo.googlepages.com/ as binary snapshot.
>>
>> There are a few pending improvements before 2038 can
>> be put on "sourceforge file releases"... The sources
>> already are on s
> PS: RBIL says that year must be < 2100, I guess this
> means that MS-DOS did not implement leap years fully.
The Int21.2A (Get system time) description says the year is below 2100 as
you said. The DOS file date format can store years from 1980 up to 2107.
Some DOS applications are limited to
> - Any DOS replacement stuff (move, tree, format...) goes to \BIN\
> - Any system enhacement (grep, ls, pcisleep, cwsdpmi, fdupdate...) goes
> to \SBIN\
Why should I want two directories with binaries? Plus, some of the
binaries might be appropriate for both \BIN and \SBIN (even FORMAT!).
Re
> What is an fnode? What does a message that more than 2 near fnodes
> are opened mean?
The fnodes are a special data structure used inside the FreeDOS kernel.
The F apparently stands for file, because the fnode contains information
about an accessed file. Early versions of the kernel used to
> we all know that it's possible to service INT 21 calls in straight C,
> with very little assembly
>
> hint: look into the FreeDOS kernel sources
Yes, by "servicing the DOS calls" (talking about the redirector, Int2F
too) I meant the initial assembler entry and setup, which is in files like
k
> It's a client and not a network drive.
So a network drive that shows you a directory of a network server would be
no network client?
--
___
Freedos-user mailing list
Freedos
>> Like I suggested an SFTP client using XMS or JLM.
>
> There are already SSH, SCP and SFTP 1 and 2 clients,
> called SSHDOS: http://sshdos.sourceforge.net/
>
>> SFTP is free, secure and wildly supported across all operating systems
>> already.
>>
>>> Is there some information about how to write n
> the goal followed by the kernel programmers was
>
> both
> ' make as many programs happy as possible. if we have to decide which
>DOS version to follow, take the younger one. '
> some (very few) internal ('undocumented') data structures changed
> between 3.x and 5.x; we took 5.x format
> I was trying to using the flat assembler FASM on freedos, but it
> complains
> about missing DPMI services ? Is it possible in some way to use it ?
Load HDPMI32 or CWSDPMI before using FASM. HDPMI32 can be loaded resident
until rebooting (so you can use DPMI programs multiple times without
> LFN for FAT and for NTFS are working stable in Linux. Could a FreeDOS
> developer grab this free knowledge from Linux and improve DOSLFN this
> way?
FAT and FAT32 are already supported by DOSLFN, even some CD-ROM
filesystems are. NTFS is not supported by any free DOS driver, so you
can't e
> "It is strongly recommended that you use MS-DOS version 7.0 (the version
> of MS-DOS that ships with Windows 95/98), since it is the only version
> that will allow you to use long filenames with your NTFS drives. Using
> earlier versions of MS-DOS restrict you to using file names in 8.3
> forma
> Originally it was 3.3 because that was a version
> which worked with most apps and still relatively
> simple. Later we got UMB
and HMA
> which are very useful so
> we aimed for 5.0 kernel compatibility. Remember
> that 5.0 and 6.22 basically have the same kernel.
> Now we also have LBA and FAT
> Which kind of compatibility does FreeDOS aim for? I mean compatible with
> which MS-DOS version? 6.22, 7.10, 8.00?
As far as I can tell, 8.00 is the same as 7.10 plus some restrictions (I
used to have a PC with Windows Me). 6.22 doesn't include LBA, FAT32 and
LFN-aware command line, so FreeD
>> After booting FreeDOS (which resides on the first partition)
>> the extended partition is marked as "Unknown".
>>
>> Partition table before:
>>
>>Device Boot Start End #cyls#blocks Id System
>> gut.bin1 0+249 250- 2008093+ 16 Hidden FAT16
>> gut.bin2
> I was remembering this thread about compatibility and thought as I did
> originally read this "Uhm, and what's the point?"
Fixing the bugs or incompatibilities (if possible) of course.
> Now I've just done
> that recently in my thread "[Freedos-user] [BUG] FreeDOS not compatible
> with escape [
Hi Eric,
> Well if it aborts then it will have a reason to do so.
> You cannot force a program to continue just by, say,
> IRETing from int 21.4c...
Yeah. But that's (exactly) what DOS-C does.
>> Disassembling parts of the MS-DOS handler
>> for Int21.4C revealed that it does:
>
> Seriously, it i
1 - 100 of 133 matches
Mail list logo
