> 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
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
> 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
> 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
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
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,
> 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
> 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
> 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.
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
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
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
> 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,
>> 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
> 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
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
>>> Why not, say, Samba? There already is smbclient for DOS.
>
> Note that smbclient has the look and feel of a text
> mode ftp client. It does not create local DOS drive
> letters for your remote network shares or anything.
Because that would require a full-blown DOS version that hooks into the
> This is already what DOS does, sort of. DOS has no separation of
> access rights, so there is no userspace, but it has a layered
> system of drivers. The kernel supports BIOS int13 drives as well
> as FAT filesystems. After booting, you can load drivers to give
> the kernel access to the sectors
> You could write such a driver but you have to remember that "DOS
> block device" already implies FAT anyway.
This implication is a part of the problem I'm talking about. DOS (rather,
the DOS device loader) shouldn't assume that just FAT exists (it also
shouldn't discard non-FAT partitions fr
Hi,
> Character devices can be found by their name and can be
> controlled via IOCTL... In addition, because you pass
> the device name as command line option to CDEX, this way
> is slightly more end user friendly than int2f handlers,
> in particular if you have more than 1 CDROM driver loaded.
N
Hi,
>>> Character devices can be found by their name and can be
>>> controlled via IOCTL... In addition, because you pass
>>> the device name as command line option to CDEX, this way
>>> is slightly more end user friendly than int2f handlers,
>>> in particular if you have more than 1 CDROM driver
> as a matter of fact, all SCSI/RAID/USB/whatever disk devices are
> either Int13-visible (using the boot eprom for SCSI/RAID or by
> emulation ), or not visible at all.
Ever heard of DOS block devices? Think of a RAM disk. It'll usually
install a DOS block device so that DOS can access it's FA
> even an unexperienced programmer should have no problem to give Int13
> access
> to his fance RAM disk
The difficulty (or inexistant difficulty) of giving some device Int13
access isn't my point. *Not* giving Int13 access for any block device is
the reason for the DOS block device architec
>> Illegal Instruction occurred
>> CS=0530 IP=3006 SS=394A SP=FFDD DS= ES=0317
>> EAXX=0100 EBX=0530 ECX=0F00 EDX=0020
>> ESI=05A8 EDI=0002 EBP=FFDD
>> Aborting Program
>
> Perhaps an EMM386 problem?
The EMM displays the message, but doesn't necessarily cause the er
Hi,
> LGPL 2: share
Where does it say that it's LGPL ?
Christian
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
> I found it in:
>
> ftp://ftp.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs/sharex.lsm
Thanks. The source file share.c from ftp.devoresoftware.com (Primary-site
in the LSM) says only "GNU GPL", as does my copy (from DOS-C 2038 SVN). I
assume the LSM is wrong.
Christian
Hi,
The MBR isn't installed by SYS, it's installed by FDISK. The source of the
standard MBR is contained in the BOOTNORM directory. (The MBR in the
BOOTEASY directory lets the user select a partition from a small menu.)
Christian
--
Hi,
> What I'd like to do is set up a separate partition on my (large, fast) HD
> and eliminate WINDOZE from this completely. I can of course buy a copy of
> MS-DOS and install this on the new partition. But I think, hang on a
> bit,
> FreeDOS ought to be just as good?
Yes it should be.
> QUE
> would be interesting to hear from Japheth how well the
> JLM interface is suited for simulating I/O port based,
> ISA DMA accessible and IRQ generating devices... Maybe
> you can somehow convince him to give an overview of
> what and how is possible and what not. I mean that JLM
> is a nice idea,
> Also, I've not tried looking at the source, but I see no reason why
> the ac97 drivers from linux couldn't be ported back to dos as a
> general sound driver, just add sb-compatible calls to it, and you
> should be all set.
The problem is that there aren't just some "SB calls" used by DOS games.
> I am somewhat confused. Freedos runs on fat32; does this mean that
> freedos
> can run any 32 bit console app?
No. The "32" in FAT32 refers to some data format on the disk; FAT32
support doesn't require a 32-bit operating system.
> In fact, how much ram can freedos access? I have usually te
> I let File system specialists rectify or detail if not right
Of course ;-)
1) Though advertised as FAT32, it doesn't really use 32 bits for cluster
numbers. Though each FAT entry is a DWord (32-bit number), the filesystem
only uses 28 of these bits. However this is a detail most people don'
The first 512 byte (usual sector size) of my in-development RXDOS.SYS file
contain code so that it's a valid DOS executable (.COM of course), DOS
device driver (try DEVICE=KERNEL.SYS), DOS kernel, and GRUB4DOS (probably
normal GRUB as well) chainloadable without special support as for
KERNE
> Note that this would mean that you have to find the sources
> of ELTORITO.SYS - nu2.nu says it is now free / unmaintained
> but sources are not yet public - and add ELTORITO and also
> SHSUCDX into the kernel itself. Otherwise you will be able
> to boot the kernel, but will not be able to load
>>> Hope you don't mind me to ask, why didn't you rather contribute to
>>> FreeDOS?
First, I do sometimes contribute to FreeDOS (i.e. DEVLOAD) and sometimes
even to the thing called "FreeDOS kernel" (or DOS-C), which is to be
distinguished from FreeDOS as a project. However I choosed not to
>> Is it possible to inject eltorito.sys and shsucdx into the kernel?
>
> You would need eltorito.sys source code first, and have
> to be aware that shsucdx is about 8 kB (6 kB UPXed, 6 kB
> or more in RAM depending on how you load it). All this
> would have to fit (preferably) into the resident-in
> I assumed you were talking about the functionality, not
> about the files! For adding FILES into the kernel, you
> would need something like that "very special boot image
> of a ramdisk, inside the kernel binary" which needs extra
> support both in the kernel (to make it visible with some
> drive
> On read-only media the 'set /e bootdevice=bootdev' will create an error
> due to write protection. How this can be solved?
Did you set the TEMP or TMP environment variable to a directory on a
writable drive?
--
Create
>>> On read-only media the 'set /e bootdevice=bootdev' will create an error
>>> due to write protection. How this can be solved?
>>
>> Did you set the TEMP or TMP environment variable to a directory on a
>> writable drive?
>
> No, there is no writable device.
>
> Well, I could introduce a ramdisk b
>> No. You could just load the contents of the files and
>> execute them so you don't have to provide a letter.
>
> You cannot "just load ... and execute", you would have
> to do it at the right moment etc.
Of course, but my point was that you won't have to provide a drive letter.
> In particular
>> Why? After all, it would be a special kernel binary used to
>> boot CD-ROMs only, so you would usually want to load both.
>
> Oh okay. Well in THAT case I think I would prefer one of two
> other methods: 1. Add very basic readonly root directory file
> read ability for ISO9660 CD/DVD to the kern
>>> 1. Add very basic readonly root directory file
>>> read ability for ISO9660 CD/DVD to the kernel,
>>
>> However this requires major code re-writing for this new driver, instead
>> of relying on working drivers. (Which only requires the kernel to have
>> this drivers's files embedded or on a boo
> Hi, I need a help, anyone here know how to access Hard Disk in Freedos?
> Mine
> is a custom copy but I able to run Fdisk and see my hard disk, however I
> can't access it, for example in Freecom when I type "C:" it says "Invalid
> drive specified". Any help?
Which partitions does Fdisk list o
Hi,
> I want free some freedos memory after using a packet driver and others
> sys
> (under fdconfig.sys) and exe (like doskey).
> There are any way to unload programs without reboot?
The best method is to use programs that provide unloading as option so
that they can properly unload themself
Hi,
>>> I am using ndn, it's good, there is a DPMI32 DOS release.
>>> http://ndn.muxe.com/
>
>> I am trying ndn. I am able to install it in FreeDOS on Virtual PC on my
>> XP machine, but in PocketDOS I get the error, "Load error: can't switch
>> mode", when trying to run the installer. Any clue ho
> website: http://au.geocities.com/short_stop_pacific/freesoft/system.htm
> look for ESCAPE / BREAK (documentation, binary and source)
>
> it's an TSR which provides to quit any application, those without quit
> button and also hanging applications.
>
> In MS-DOS 7.1 with no config.sys/autoexec.bat
>> Which application do you abort?
>
> None. No joke. I just boot the pure kernel (no configuration files),
> start escape and press F12 - in MS-DOS no crash - in FreeDOS crash.
Well, do you load COMMAND.COM (or FreeCOM or whatever CLI)? That is, do
you have a command prompt? "The pure kernel" c
> Indeed, sorry.
No reason to feel sorry for this.
>> That is, do
>> you have a command prompt?
>
> Yes. Otherwise I couldn't load escape.
You're right, I should have thought about this before. Without some
special hack and if there's no CONFIG.SYS that could INSTALL= the program,
this isn't
> FreeDos Command.Com vs 4DOS
> Can someone explain the differences please?
> Which is the prefered one?
FreeCOM (the name of FreeDOS's COMMAND.COM) mostly aims to be compatible
to MS-DOS COMMAND.COM. 4DOS doesn't, but it provides many new functions
and features. 4DOS may not work with complic
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
> 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 [
>> 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
> 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
> 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
> "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
> 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
> 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
> 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
>> 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
> 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
> 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
> 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
> - 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
> 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
>> 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
> 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
>> 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
>>> 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,
> 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
> 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
> 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
> 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
>>> [...] 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
>> 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
> 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
> 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
>> 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
> 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
>> 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
>>> 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
>> 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?
--
> 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.
-
>> 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 ?
>
>> 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
>> 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
---
> 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
> 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
>>> 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
> 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
> 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
> > 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
>>> 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
> 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
> 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
> 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
> 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
>>> 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 (
>>> 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
> 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
> 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'
1 - 100 of 133 matches
Mail list logo
