Re: [Freedos-user] New release of DOSUTILS package
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 be simpler, and would suffice in at least most cases. Regards, Christian -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] New release of DOSUTILS package
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 advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] mTCP 2011-05-20 Version
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 conversation though. Should you refer to me here (I highly doubt you do not) then please ensure not to misrepresent my opinion. I am not aghast at your choice of license. Though as has been stated it is true that personally I would have _preferred_ a license other than the GPL. It is obviously your choice. As I pointed out I appreciate your source code release nonetheless. If you want to further express your amusement at me please keep that to our forum. I will not reply to other posts about that on this mailing list. -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Problem with UIDE
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, Christian -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] if not exist MD XXX
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 directory doesn't exist. In NTVDM, it does work as well (only?) using the COMMAND.COM supplied with NT; however, with other COMMAND.COMs (including FreeCOM) it indeed doesn't work: device names (such as NUL and CON) apparently aren't found. So while checking for a directory's existence with this method might work in non-DOS NT batch scripts, it can't be relied upon because the NTVDM's DOS interfaces appear not to find device names. Regards, Christian -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] if not exist MD XXX
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 MSW program cmd.exe (which obviously doesn't use NTVDM-DOS's FindFirst) the NTVDM-COMMAND program (which at least partly works as V86-mode DOS program) does find the devices too. I guess it might not use the NTVDM-DOS interfaces internally and hence finds the devices. This would indicate NTVDM-DOS's FindFirst and FindNext are broken (incompatible) in some way as you suggested. I didn't get into the specifics earlier 'cause I didn't think it was necessary. Regards, Christian -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] No kernel sys
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.gwdg.de/pub/misc/freedos/files/dos/kernel/2039/ Yes, for example. The kernel is also available from FreeDOS's SF.net project (http://sourceforge.net/projects/freedos/), and the software list contains a link to the ibiblio FreeDOS mirror (see http://freedos.sourceforge.net/software/?prog=kernel). Ask again if you can't get it to work with the updated SYS and kernel. Regards, Christian -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] location of autoexec.bat?
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 some reason for this restriction. Apparently no one saw a need for that. For symmetry, you would have to provide a writeable (FD)CONFIG.SYS file too (which is harder to accomplish). In both cases, these files should probably _replace_ the ones on the CD. Additionally, your drive C: could be some read-only device (or one you don't want to modify) too, or maybe there isn't a drive C:, or whatever. Even something as simple as saying that we always execute the file C:\FDOS\CDAUTO.BAT (for example) if it exists, does not appear reasonable to me. I'll just have to write my own batch file and remember to execute it manually on startup each time. That's the best workaround you'll get with the CD as is. Yes, it does need to run natively. It needs real-time access to the real hardware, and it needs to be in an environment in which nothing else is going to steal cycles. Then I suggest you install a whole FreeDOS installation (or only the boot disk of the CD, or only a small installation containing everything you need) on your R/W storage (hard disk) and boot that. The live CD isn't intended for this usage. You can update the writeable installation with newer programs then, too. Regards, Christian -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] No kernel sys
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. This is not related to your problem, unless your drive C: (atypically) is a logical partition. Primary partitions should work just fine. The mentioned tweaking is meant for developers. Make sure the file KERNEL.SYS exists in C:\. Update to kernel 2038 or 2039 (from the FreeDOS mirrors) and use the updated version of SYS in there to install that kernel. If that doesn't make it work, try using the SYS option to force the access method to LBA or CHS. You can also try the option that will hard code a BIOS drive number (usually 80(h) is the right for hard disks) into the boot sector instead of relying on the BIOS to provide the correct one. Regards, Christian -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Watch out for Windows 7
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, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Problem w/ CONFIG.SYS INSTALL
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 would appear so. It might be possible that DosComLoader tries to give the COM all available memory and unless you specify otherwise when going TSR none is left for others, but thats just guessing. Bret allocates other memory blocks, so he does resize the process first as necessary. (As an aside, such a situation should not make the kernel crash like that.) Is your TSR a COM or is it EXE? Does it keep handles open? Does it use environment variables or other PSP related data? Does it make a difference whether to INSTALL or INSTALLHIGH? Educated guess: COM, no (shouldn't matter though), no (except as allowed, before the TSR is resident), no (Bret said so). Regards, Christian -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Problem w/ CONFIG.SYS INSTALL
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 one right now, but it's one from right after FreeDOS version 1 was released. I'm working with some other programmers who are using the latest versions of the kernel. I can find out exact details if it might help. Yes, details would help. I would strongly recommend you to update your kernel, that might fix the problem. Regards, Christian -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] internationalization ... KEYB bug? ... i18n-DOS ... Greek, Esperanto ... kernel 2039
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. Yes, maybe the bugs are/bug is limited to some versions. which could then overwrite things in RAM, Which would be a bug. Jumping to 0:0 could mean a pointer/handler is used before being set. Good call. Regards, Christian -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] internationalization ... KEYB bug? ... i18n-DOS ... Greek, Esperanto ... kernel 2039
(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 loads correctly. (Part of this was my confusion with trying to learn what Greek needs, 737? 869?) Whatever, but it's not even working as good as I previously confirmed (year ago?) with cp853 (Esperanto). I almost want to think it's a 2039 kernel bug, but I highly doubt it. :-( XMGR, HIMEMX - Invalid opcode (is that the kernel saying that???) Probably. Could be the BIOS, but I think the kernel installs a handler. JEMM386 - Exception at CS:IP : ... Press Esc. to quit. I'm just lucky it doesn't crash the whole thing, sheesh. It *does* crash the whole thing. You just had luck that during the crash it eventually encounters an invalid opcode somewhere. Just curious if anybody knows what's wrong, what to try next, etc. I think it would be nice to demo the i18n features of FreeDOS. (Maybe I should try putting the files on a more reliable medium like hard drive and see if that helps. I would definitely feel foolish if that was the solution. But anyways ) Could you send links to the necessary files (specific versions of KEYB, DISPLAY, MODE, CPIDOS, etc) to create that floppy, or to an image? I can try debugging it (need test cases anyway). Regards, Christian -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] svn failure
(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 program you are downloading and from which repository. From the message that you have shown, I would assume it's a problem with the file mem/branches/mem14/... (yes, it's named like that) in the FreeDOS SVN repo. (This file is shown by the SVN browse sf.net interface.) ... is not a valid file name for DOS or Windows file systems. Regards, Christian -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] LBA and clusters
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 addressing sectors, regardless how formatting groups them or not. Right. Additionally, I want to clarify this: the FAT file system clusters should not ever be relevant to your BIOS in any way. The BIOS (in most or all cases) does not know anything about files, file system clusters, file systems or (MBR) partitioning beyond access to numbered sectors. Whether the sector numbering is LBA or CHS, or whether low-level translations such as 1 BIOS sector is 8 physical sectors are used does not in any way affect DOS in dealing with FAT file system clusters. The units of such low-level translations might be called clusters by your BIOS or hard disk vendor, but (by what you wrote us) I do not believe these are associated with the FAT file system clusters in any way. Besides, you don't have to turn on LBA. If CHS addressing works correctly and your entire disk can be accessed by it, it usually doesn't matter much whether you enable LBA. It would be interesting to know what size of these units are used by your BIOS and hard disk. When you say 1 logical block = 8 sectors, how large is one logical block and how large is one sector? When you say sector, do you mean the physical sector on the hard disk? Likewise, do you mean the unit accessible by software when you say logical block? Does this translation happen only with LBA access, or both with CHS and LBA access? It would be nice if you could find out more about this. Regards, Christian -- Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Fwd: File corruption
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 systems (called FAT32 kernel) and one that only supports the FAT12 and FAT16 file systems (called FAT16 kernel). I think this is what was meant here. As Tom said, the issue appears to be specific to the FAT16 kernel (i.e. the one that doesn't have FAT32 support). Besides that, there is (or was?) a kernel optimized for 386+ CPUs that is able to use 32-bit instructions (although it still executes from within a 16-bit memory segment as usual) and therefore might utilize 32-bit registers. This kernel only runs on 386+ CPUs. For kernels 2038 and 2039, such binaries currently ain't provided on the FreeDOS mirrors so you would have to compile such a kernel utilizing 32-bit instructions yourself to use it. Regards, Christian -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] file corruption
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 if that is not the case. Regards, Christian -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Processor overheating under DOS
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 pressed. This apparently was no problem at some time but now makes your CPU eat a lot more power and produce a lot more heat than is necessary. This design fault was and is inherent even in the BIOS servicing code for user input. As Mateusz said, using FDAPM APMDOS or a similar setting should cure the primary reason this happens. It does so by hooking the DOS and BIOS functions which are called by idle-unaware programs (90% of DOS software), and replacing the DOS/BIOS code with a loop that (a) calls a different DOS/BIOS function to check whether a key is currently available, (b) if no key is available, halts the CPU til the next hardware interrupt (usually timer or keyboard), and (c) otherwise gets the key from the flawed DOS/BIOS code. These won't unnecessarily stress the CPU if the key is already in the BIOS's buffer so it's okay to call them if you know that there is. Regards, Christian -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Processor overheating under DOS
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 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Processor overheating under DOS
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-aware handler of the call could provide correct idling. This particularly means that DOS can fix incorrect applications, if they call DOS, and that the BIOS can fix DOS (because DOS always calls the BIOS) and all applications that call the BIOS. Though I have not yet seen a BIOS that idles correctly (even on recent boards!), there might be some that do. Regards, Christian -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDos-user, SoundBlaster ?
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 learn to program in C and Assembly language and write a JLM Sound Blaster emulation driver based on MPXPLAY's drivers. Regards, Christian -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Processor overheating under DOS
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, though I wouldn't recommend it, I don't care whether you let your CPU run at full workload either. Regards, Christian -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS USB Device Problem
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 specify any exact error messages that appear and describe your system and relevant details. More importantly, tell us what executables you executed, and with which parameters. You may also want to report this to Bret directly, or on his forum, as he usually will tell you why the drivers might not work and assist you with technical problems. Or if there's another good choice, pls. show me an example about that. There are some other USB drivers floating on the net but I don't know any specifics any more. The one set worth mentioning is Georg Potthast's recent drivers but they have several practical disadvantages. Nonetheless, you are free to check them out on his site: http://www.georgpotthast.de/ Regards, Christian -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDos-user, SoundBlaster ?
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 anything except games - the main DOSBox distribution is tailored to support DOS games so non-game applications might not work as well. (I.e.: they just don't care about any other applications and so their DOS partly is lacking.) Regards, Christian -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDos-user, SoundBlaster ?
- 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 / early Pentium PC emulator) No, the file system support is quite useful. Rather, remove the pseudo-DOS around it entirely - but retain the file system mapping as a file system redirector that would be installable in the emulated DOS (similar to *CDEX and other file system drivers). Regards, Christian -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Incompatible file system checking results
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 addressed using LBA? If your hard disk is larger than 8 GiB and the partition is partly or fully outside the first 8 GiB of the disk, then that might lead older SCANDISKs to work improperly. Regards, Christian -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Help: FreeDOS hangs when select memory management method
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 as well. I would recommend updating HIMEM with HIMEMX (from the same page as JEMM) too. You have to do the same as with JEMM for that, just instead of EMM386.EXE replace the file name of HIMEM.EXE with HIMEMX.EXE. Regards, Christian -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Help: USB drivers for USB mass storage devices
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 driver, IIRC a CONFIG.SYS device driver): http://www.georgpotthast.de/usb A demo version (don't know about limitations) is available for free. Otherwise, see this site for licence/prices: http://www.georgpotthast.de/usb/licencen.htm Bret Johnson's USBDOS package currently includes support for UHCI (some USB 1.x) controllers only. This means it won't work with OHCI (other USB 1.x) controllers, and will only work at USB 1.x speeds with EHCI (USB 2.0) controllers if they have a companion UHCI controller. Most EHCI controllers either have UHCI or OHCI companion controllers. It comes with a disk driver TSR and some others. The programs and their entire source code is available free under a simple Copyleft-license (i.e. derivative programs have to use the same license) from Bret's pages: http://bretjohnson.us/ Regards, Christian -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] doing graphics
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 an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Dualboot with Knoppix?
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 that. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] very small FAT12 partition?
- 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 standard size floppy image) The CHS information is usually ignored by the driver and might be bogus. It sure is ignored if the partition is accessed directly by the operating system (from a file or RAM or ROM). Note that the FAT file system internally uses a sector addressing scheme like LBA: there is a sector number that counts the sectors starting from zero. Nothing else. The FAT driver doesn't care about heads and cylinders that might be addressed at a lower level. The boot block is also called boot sector, but not MBR (Master Boot Record). The MBR isn't contained in any partition. - one or two FATs (starting with the magic code), big enough for your *data* blocks You certainly want only one if you have to utilize a very small partition. Regards, Christian -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] very small FAT12 partition?
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 not manage to recreate a similar one. Therefore on Linux I tried mkdosfs -f 1 -F 12 -h 0 -S 512 -C partition.iso 4 but it fails with the error message that this partition is too small. The smallest I could build this way was 34KB in size. Could you give me any hint how to create a partition smaller than 34 KB? If there's no tool to do what you want, you might be able to create it yourself with an assembler. For this, I found a nice NASM (the Netwide Assembler, at http://www.nasm.us/) macro to create FAT12 images on this german blog: http://superschurke.wordpress.com/2006/06/09/mit-nasm-fat12-images-erstellen/#more-5 (Don't worry, you should be able to copy and read the code without problems even in case you don't speak german. Though if you need a translation, don't hesitate to ask me for it.) Regards, Christian -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Determining partition types (NTFS, etc)
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 liberaly. I've only ever heard it used to mean *all* file systems using the VFAT extension, i.e. FAT12, FAT16 and FAT32 file systems with long names. They probably call this the VFAT file system to distinguish it from their original FAT file system implementation which didn't support long names and the new file times. (BTW, the V stands for Virtual which at most fits into Microsoft's strange behaviour of calling everything related to Win386 virtual, and doesn't relate to what a VFAT file system is in any way. They probably only named their VxD VFAT, and with this implementation being the first one to support the new features, someone just called these features VFAT.) Regards, Christian -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] freedos - Modern sata dvd dual layer not found
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 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Odd behaviour involving mouse
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 Int28 handler itself does nothing. FDAPM however might execute another HLT in its Int28 handler resulting in bad performance. You'll get the best performance with no HLTs at all, but one HLT before/in Int28 (IDLEHALT=1 but no FDAPM?) shouldn't affect performance badly either. That might be related to how exactly the application writes to the screen. Regards, Christian -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Fwd: DOSLFN discussion on FreeDOS user list
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 second issue (collisions handled improperly) is only RAR32's fault. Regards, Christian -- List, Below find a forwarded message Laace send to me. --- Weitergeleitete Nachricht --- Von: Laaca la...@seznam.cz An: cm c...@bttr-software.de Kopie: Betreff: DOSLFN discussion on FreeDOS user list Datum: Sat, 21 Nov 2009 12:44:14 +0100 Hi! I read the discussion about problems with DOSLFN in particular situations in FreeDOS. The described example is quite hard to reproduce but I know another one and much easier to track. DOSLFN doesn't work properly with RAR32 for DOS and OS/2. If archive contains long file names they are truncated into 8+3 names and the name collisions aren't properly treated. If you want to decopress such archives you have to use the windows console version which fortunately runs perfectly under HX. (Note that this trick fixes also another problem of DOS version of RAR - the unability to run on computers with 512 and more MB RAM) I am not registered to FreeDOS users list (I am only at developers list) so, please, forward this message into it. --- This e-mail has been sent via the forum (http://www.bttr-software.de/forum/). -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOSLFN and File Wizard
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 didn't corrupt anything yet. The way DOSLFN is implemented however is messy; it depends on DOS's behaviour (it was developed on MS-DOS 6.22 and 7.10). Either DOSLFN depends on something it shouldn't, or the FreeDOS kernel fails to behave similar to MS-DOS somewhere. (Or both.) A FreeDOS kernel developer would have to work through the DOSLFN source to check this. Regards, Christian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Question about ripcord
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: a mov ax, 33ff int 21 enter on blank line t t r d value in DS:value in AX All it does is use a to switch debug to assembly mode, input the instructions to execute the kernel interrupt that returns the version string, then trace just those two instructions (do not run with g), display the registers so you can see the values returned in DS:AX, and then using those values display (dump) the data there. The pointer is returned in the DX:AX register pair, not DS:AX. With FreeDOS DEBUG, the registers can directly be used in the d command, too. These lines can be entered on FreeDOS DEBUG's prompt then: a mov ax, 33ff int 21 t t d dx:ax The first ASCII zero (00 in the hex view) ends the returned string. Enter a single q on DEBUG's prompt to exit DEBUG. Regards, Christian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Reporting two tiny problems
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 CONFIG.SYS, but I tried modifying it and the same thing happens Might be related to the fact that option #4 doesn't work since there's no line which uses option #4. If you understand the FDCONFIG.SYS menu structure, add some line which does nothing and is executed for all options. 2) If I'm running FreeCOM (COMMAND.COM) and I run an application with a command line and add a redirection operator, trailing spaces after the command line and before the operator will be passed to the application, often causing it to fail the purpose of the command. For example, if I type MYPACK myfile.dat result.txt, I may get a message like File not found: 'myfile.dat '. Or more common, if I enter EXTRACT thisfile.pak |more, it may come up with Invalid file name: 'thisfile.pak '. Extension should be '.pak' or '.zp'. Things like that I know I can easily avoid these instances, but in the event that they are easy to fix, it's something. This behaviour is consistent with MS-DOS COMMAND.COM's. Fix your programs to cut any trailing and leading whitespace (tabs and spaces) from the command line before using the filename. Regards, Christian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Error loading OS: FAT32-LBA problem or something else?
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's MBR, boot sector or kernel contain this message. Thus I'd assume it's from the Windows MBR. (I'm using a localized Windows so I can't compare it to the message of its MBR.) a Western Digital 160 Gb disk, in the typical marketing way of using powers of ten, not two, so it really has about 149 Gb. Use binary prefixes then. I offer this info only to demonstrate that Grub had been capable of booting something beyond where XP was installed.) I'd created the FAT-32 partition from XP using the disk manager. Then you might have created a logical partition. You might not be familiar with the difference between logical and primary partitions. However, the default Windows and FreeDOS MBRs don't support booting from logical partitions (GRUB does), and that's most of the difference anyway. Even with GRUB, the FreeDOS kernel might not work when booted from a logical partition. Ask the kernel developers about that. GParted should display whether your FAT32 partition is a primary or a logical one. (Logical partitions are contained within extended partitions.) If you recreate the FAT32 partition with GParted, it should also allow you to select whether it should be logical or primary. (Personally, I'd prefer GParted over the Windows disk manager for most partitioning-related work anyway.) I made the FreeDOS partition active from XP, and tried rebooting. This generated the error message above. That Windows allowed you to make the partition active is strange. If it really is a logical partition, it shouldn't allow you to do that. If my assumption is wrong and the partition is a primary one, everything should work fine for you. Speculating the perhaps the installation hadn't installed a partition boot sector to the FAT-32 partition, I rebooted the FreeDOS CD, went to the C: drive, and issued the command sys C: which reported sectors/trk: 63, heads: 255 hidden: 78397200 FAT starts at 4AC3F10 + 26 (78397200 + 38) Boot sector load seg ... 60h The word hidden next to the number that curiously matches where FAT starts has me suspicious, for some reason. :-) Hidden sectors is the usual term for sectors in front of this partition, and was just abbreviated to hidden here. FAT starts means the first FAT's first sector, which of course is inside the partition. It's somewhat useless, but this message from SYS always displays the same number twice. Anyway the hidden number doesn't mean the partition itself is hidden at all (although I understand your suspicion). I found a prior article on the mailing list in which someone reported, around 2007, that FreeDOS had problems with FAT32, sometimes mistaking FAT32-LBA for FAT32-CHS, or something to that effect. It might be caused by this. You can update your SYS program with a version from kernel 2039 first, that could fix the problem already. This version of SYS also allows you to overwrite SYS's broken auto-detection (the only actual problem) using the option /FORCE:LBA (which isn't documented for some reason). The author indicated that there exists a Perl script (!!!) to fix this. Sounds adventurous. That might have refered to the Linux script which was written so a boot sector could be written to a DOS partition from Linux. This however is a SYS replacement, not a fix for the broken SYS. It won't help you if an updated SYS doesn't. Does anyone have insight into this? Is it the 1024 cylinder problem? If anything with cylinders is involved, SYS would have installed the CHS boot code (which can't work for your partition). With LBA, the boot code and kernel and operating system don't have to care about cylinders or heads or tracks at all. Is there a practical workaround besides using FAT16 (kind of ugly for an almost 1 Gb partition)? FAT16 possibly wouldn't help either. And I'd use it only for partitions up to 512 MiB anyway, anything larger than that is inefficient. Sorry for the long message. I'm never sure how much detail to include. I know that too little is pointless, since nobody can help if they don't have the facts. That's right. So writing a long mail is indeed better. You don't have to apologize for that, even if we don't need all information you sent. Regards, Christian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
Re: [Freedos-user] Booting without hard disk
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 are easy to break off. Break how? Breaking off means falling out of the port or being disconnected by accident. I'd definitively prefer CD-ROMs or HDDs as well, simply because I won't depend on good BIOS USB drive support for DOS. As Eric mentioned, there are adapters which allow replacing HDDs with CF cards. There are also SD card adapters but these contain an actual chip and therefore usually cost more. (Both of these adapter types look to the BIOS and software exactly like a HDD.) Regards, Christian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Malware5.
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 them encapsulated in compression files, yet the gmail balks at one and not the other? --kurtwb2...@gmail.com. Gmail blocks executables, some archives with contained executables and some archives generally. This also depends on the archive type and encryption. (Even worse, incoming mails might be blocked without you or the sender being told.) Regards, Christian -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Disk checking and defragmentation
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 damaged files. In addition, strange folders or files appeared which could not be deleted. To get rid of them I had to copy the usable files to a second hard disk and reformat the first. This happened three or four times, in two different computers. Did you use the latest DOSLFN version (from Jason Hood)? More importantly, notice that DOSLFN can be disabled or unloaded without rebooting. Did you disable it (or restarted the computer, without DOSLFN) before running CHKDSK? I'm uncertain about this, but enabled DOSLFN might cause weird CHKDSK (or DOSFSCK) behaviour. Disk-caching software such as LBACACHE or SmartDrive might also lead to problems (either stand-alone, or only in combination with DOSLFN). Do you use any cache? For instance, I have not been able to understand how to use the DOSFSCK with the -V perform a verification pass option. The logic behind it is clear: let's have a look at things before changing them. But when the program runs, it just writes: dosfsck 2.11.DOS3, 8 Aug 2007, FAT32, LFN Starting check/repair pass. Starting verification pass. c:: 33412 files, 42820/65505 clusters That confused me. Does it mean the disk is OK? Is there anything else to be done? Yes, such a screen means DOSFSCK didn't find any error either in it's first pass or in the verification pass. I usually run DOSFSCK with the -r and -t options too, which enable interactive operation (DOSFSCK will prompt you what to do on errors) and testing whether clusters are bad. Your appended NSSI report says there's no XMS (HIMEM) or EMS (EMM386) driver installed. Is that your usual configuration? This might cause problems. I think DEFRAG and software ported to DJGPP (such as DOSFSCK) might run better with XMS than with raw extended memory. Regards, Christian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Over 4-GB for FreeDOS, Etc.
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 can contain files, sure, but the ramdisk itself has no idea what a (FAT) file is. It only needs to provide an initial state which looks like an empty formatted FAT filesystem. NO misunderstanding, and that is exactly what RDISK and other RAMdisk drivers do. After setting RAM memory to an initial state, a RAMdisk does memory-moves, not file transfers, with a one-to-one correspondence -- every DOS read or write to a RAMdisk causes exactly one XMS move request. Thus, one is better-off viewing a RAMdisk as a FILE handler, rather than a sector handler. Looking from DOS, the RAM disk is a block device. It doesn't handle data on a per-file basis; I don't understand why to call it a file handler then. It handles or provides sectors to DOS and that's it, so one is better off viewing a RAM disk as a sector handler. The Phantom RAM disk presented in the Undocumented DOS books was a file-based RAM disk: it hooked the redirector interface and provided the appropriate functions for each file. These files were stored in Phantom's own file system, in RAM. (Of course it makes more sense to use DOS's built-in file system driver, but the UDOS guys just did it to show how the redirector interface works.) Unless you recently changed RDISK to use the inferior redirector approach (that was a joke), it's still a block device as last time I looked at the source. What do you define as DOS read? Calling the Read from file DOS function? If that's the case then you're wrong, DOS usually calls block devices multiple times to read the FAT and the necessary sectors of the file's data to carry out such a request. If you meant DOS read as reading a single or some sectors from a block device, this is correct. Regards, Christian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] RAM disks jokes (Was: 4 GB for FD etc.)
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, this is correct. Fine, Christian, that is EXACTLY what I meant! Thank you for clarifying this. Thus UIDE is a pure SECTOR handler and Couldn't care LESS about any DOS directory structure. Our whole point is: Except when the data is initialized, the quoted text applies for a RAM disk as well. I won't go into more details regarding file allocation tables, file systems or formatting now because it won't be worth my and your time. However there's something we can agree on: to the user, any RAM disk (whether using a block device or redirector approach) is made up of a drive letter possibly containing directories and files. Naturally, this explanation doesn't cover any technical details at all. I wish you Lots Of Luck dealing with those who MAY NOT be as forgiving of your jokes, Yes. I'll try not to tempt you with any more complicated phrasing. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Over 4-GB for FreeDOS, Etc.
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 manager (EMM386) disables ancient DOS extenders which have to start from real mode (i.e. pre-VCPI). so it is good that HIMEMX and JEMM386 are still separately available. Separately from what? Regards, Christian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Over 4-GB for FreeDOS, Etc.
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.e. JEMM being the best available PM memory manager) but the answer doesn't fit what Eric said: At the moment, JEMMEX already is too fancy for many ancient DOS games which use pre-VCPI DOS extenders, so it is good that HIMEMX and JEMM386 are still separately available. Also, isn't JEMM actually FreeDOS's memory manager of choice? I suppose there was such a thing as FreeDOS EMM (that from which JEMM was created) but is it still maintained? Regards, Christian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Whatever happened to freedos-32?
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 will replace the current one. Here's what he wrote me: Salvo Isaja, 2008-05-27: Now proceeding with very slow pace and restarting since the very beginning, mainly due to licensing issues (i.e. the GPL is unadeguate). [note that the GPL is the license of OSLib, not LGPL] Reading some old mailing list archives I found, I think it's something about the licensing of OSLib. As previously discussed in the BTTR Software forum, DOS-C (The FreeDOS Kernel) possibly violates the GPL by allowing to load non-GPL DOS device drivers. Now in FreeDOS-32's architecture the native drivers and applications are linked into the kernel or something, so the OSLib guy said they all have to be licensed under the GPL too when using OSLib. Regards, Christian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS-C and GPL (was Re: Whatever happened to freedos-32?)
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 somehow. The comparison of drivers to OSLib is an apples and oranges comparison. I compared DOS device drivers to the native applications and drivers of FreeDOS-32. (OSLib only comes in as FreeDOS-32 is currently based on it.) A DOS loadable device driver is simply an executable that is loaded into memory that follows a certain calling convention. Depending on the executable type, it may be relocated by the kernel. FreeDOS, or any GPLed MS-DOS alternative, would be totally useless if it disallowed non GPL device drivers, since the vast majority of device drivers are non GPL. Of course. But please read that discussion first and then tell us it doesn't apply: http://www.bttr-software.de/forum/forum_entry.php?id=6796page=0category=0order=last_answer Besides, Richard Stallman is well aware of our project and would have contacted us if he felt we were doing something wrong. I wasn't aware Richard Stallman is a DOS internals expert. Please don't argue by showing me people which don't believe in something, rather, stay with actual facts about the kernel and device driver interface or the GPL. Regards, Christian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS-C and GPL (was Re: Whatever happened to freedos-32?)
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 trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] printing to USB
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 me a program that counts the total lines of NASM source files, but also showing how many lines contained nothing (blank), only a comment (with ; or as block with %if 0) or actual code (labels or instructions). Who will ever be able to understand and update Georg's host driver? Certainly not anyone except him, since it's closed source. The interface is well-documented and you write software for Windows, Linux, DOS without reading their source, too. And if the people that own the Windows source decide to abandon that Windows version, you aren't able to understand and update it proper either. (understanding means to understand the internal working, i.e. the source code's operation, because I write in response to your might not understand large project.) My point isn't not to write drivers for either software, it's that closed-source software is abandoned if the ones having the source don't update and support it. This doesn't affect users of the software or using it directly. I'm not interested about that. Even if Georg's drivers are faster, I trust Bret's work more Why that? As mentioned, I looked into some of his work. Plus I'm annoyed at how long it took Georg to understand a simple issue of his drivers I asked him to fix. What do you mean by compatibility? Support for most different USB controllers and USB devices. When Bret's finished with UHCI support, both drivers will support the same host controllers. Support for devices depends on which drivers are available for that host software. I think both currently support disks/drives, mice, keyboards and some ports. Apart from IRQ support (good idea) the modularity is similar in both. Are the host controller drivers modular too? This is the part of the host driver which interacts with either EHCI, UHCI or OHCI hardware. I think the 4DOS case was some sort of misunderstanding which later got clarified into a more universal license. Which didn't contain much of the FreeDOS exception stuff anymore I think. All of these programs, as well as their documentation and source code, are freely available to anyone who wants them. Maybe add BSD or Artistic license then :-) BSD doesn't have Copyleft, and it allows turning the program into commercial software. Which Bret doesn't want. Please read through the full reply and discard inapplicable answers then. You also cannot distribute the programs, documentation, or source code and charge (even indirectly) for their distribution. Similar to shareware days - do not charge for distribution. Only that shareware is different - it disallows charging because the author wants to sell it, and doesn't want to lose profit by others selling his stuff. The stack and some of the drivers ARE small because they ARE already written in ASM. I worry that Georg isn't really good in Assembly. Just some of the examples are in BASIC maybe because that could be easier to read. BASIC easier to read than Assembly or C? Than both the Assembly and C code must be obfuscated a lot first. How could BASIC be easy to read? Note also that the low-level calls to the API are almost inline Assembly anyway, working with specific registers and interrupts. Linking an external object module is much better if Assembly parts are required. Regards, Christian -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] printing to USB
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 host driver? Certainly not anyone except him, since it's closed source. I hope at least Bret still understands it :-). What's your point? Good code is easier to maintain than bad code, and by what I've read from him (I previously looked at some of his other programs, before he released the USB stuff) his code is very good, commented a lot and easily understood by anyone able to write in that programming language. I am really curious about performance and compatibility comparisons between the Bret Johnson USB drivers and the Georg Potthast drivers. I'm not interested about that. Even if Georg's drivers are faster, I trust Bret's work more and think he's faster and better regarding support. What do you mean by compatibility? If they both give access to the packet layer (the Georg Potthast one does, afair) through their APIs in some way, it should be possible to write a wrapper: Then you could use device drivers made for one of the 2 USB stacks with the respectively other USB stack :-). I would prefer if a single host driver would become a standard - making such wrappers, which could potentially cause a lot of bugs, unnecessary. By what I've read from Bret's documentation, the wrapper thing might be impossible anyway - Bret's host driver is designed for interrupt-driven background execution. (Since it's modular too, meaning that the main module only contains the host driver, the specific device drivers for things such as disks and pen drives have access to the USB packets using the API.) As said, the FreeDOS OEM edition of the G.P. drivers is free for any use with FreeDOS and has public domain device drivers but a closed source freeware USB stack, Last time someone provided a FreeDOS special licensing (I'm thinking of 4DOS) it wasn't really accepted. Why? Because FreeDOS seems to imply that it can be used on FreeDOS systems only, but not on those running MS-/PC-/DR-/EDR-/PTS-/RxDOS instead. (Whether a system is defined by the kernel only or by a set of distributed programs doesn't matter in this case, it's bad either way.) while the B.J. drivers are completely source available but I could not find the license details for that one. Read the documentation. It doesn't state that it has XYZ's license, but the provided explanation clearly states how the programs are meant to be used. I'll cite USBINTRO.DOC a bit: All of these programs, as well as their documentation and source code, are freely available to anyone who wants them. Should be less difficult to understand. You can use the programs without restriction, but you cannot directly or indirectly use the executable programs, documentation, or source code to create or distribute new programs that are not also freely available. It contains some sort of Copyleft. You also cannot distribute the programs, documentation, or source code and charge (even indirectly) for their distribution. From this, and what I've read from Bret elsewhere, it seems that you aren't allowed to sell the program/documentation/source itself, but usage in a business shouldn't be restricted. (Just ask Bret if in doubt, it's his work.) Note that the cited parts aren't the full license as stated in USBINTRO.DOC. There you'll find some more text with clarifications and such. Essentially, the license is mostly similar to the GPL [version 2] (with emphasis on the mustn't-sell-it-itself point) but MUCH shorter and easier to understand. Regards, Christian -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] update: dos extenders=HX.
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 does not make the conversion? I am a bit thick sometimes, but I didn't seem to see anything in the HX package to make that conversion. If it complains that it needs PE executables, it's from the HX DOS extender to run Win32 programs in DOS. To run DJGPP executables, simply use HDPMI32 (which is part of the full HX DOS extender, but acts as stand-alone DPMI server too). There's some way to stub that directly into your (DJGPP) executable as well, or to replace the loader that searches for CWSDPMI.EXE by one searching for HDPMI32.EXE instead. Read the HDPMI/HX documentation, I think it tells you which files contain what type of loader. Regards, Christian -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Two non-bug reports.
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 here as usual. The solution is much easier - discuss technical details on freedos-devel and basic things on freedos-user as usual. Maybe recently more people discussed technical details on freedos-user because there is more activity there than on freedos-devel? Of course this should not be a reason to migrate threads or even start yet another list... ;-). Often threads started normal on Freedos-user but the discussion got technical later on. I don't want to be accused of geekifying anyone's list, so I'll simply stop writing any answers here that might be useful to developers for fixing the problem. Good that I'll never have to provide a user mailing list for my software. -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Two non-bug reports.
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 support, so they misidentify the partition as FAT12. For test purposes, I made a version that accepted the vendor byte FD (FreeDOS) instead of FF (MS-DOS) and it worked, but anything used in production would have to use a different method to determine whether FAT32 is supported (FreeDOS comes both ways, and there are several DOSses today that support FAT32.) There is similar logic that determines which versions of DOS require volume locking (MS-DOS 7 or later.) Fortunately the LFN-EN utilities are open source, so someone could fix this. A reliable FAT32 test method is to check whether a common subfunction of Interrupt 21h, Function 73h (FAT32 extensions) is supported. I disregard any method that works per DOS version. Users apparently don't want technical details on the Freedos-user list however. Regards, Christian -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Minor nit: Norton Utilities slow with FDAPM APMDOS; FDAPM APMOFF fixes.
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 something. Try FDAPM APMBIOS. Does it still affect the program's performance? APMDOS hooks too many interrupts. Regards, Christian -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Fwd: Announcement: New DOS USB Drivers
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 -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Incompatibility with EMSDSK #3
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 Note the reported free value. ... It seems that FreeDOS does not work well with real-mode UMBs, since EMSDSK no longer shows any problems if I rem the first line in CONFIG.SYS and change the NORAM option to RAM. Looking into UMBs (when they are real-mode), I found command.com there, possibly overlapping the EMS frame area. If any UMBs (provided by RDOSUMB) overlap the EMS page frame, this is a certain source of errors. Using your current configuration, inspect which areas of the UMA are provided as UMB and whether any of these areas contains or crosses segments E000h to EFFFh (where the 64 KiB large EMS page frame is). One of the MEM options might show you the (hexadecimal) segments and their size. (If you don't know how to look at the segment and size values, send a list of your UMBs with these values to the list.) If I omit the FRAME option in CONFIG.SYS, then I see thismessage during boot: *** EMS RAMdisk v1.9I (FU - 08/98): ems get frame error and EMSDSK does not install. The memory map in this caseshows no EMM0. Note that EMSDSK might be able to work without page EMS frame, giving you more UMB. Apparently not. You might of course try FRAME=NONE first and see if EMSDSK shows the same message. However many other EMS programs don't work without page frame anyway so I won't recommend running such a system. If you don't use any other programs that require EMS, a better option might be to disable EMS completely (JEMM option NOEMS, and remove FRAME=) and replace EMSDSK by XMSDSK (or the open source RDISK, which also runs with XMS). Regards, Christian -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] USB Question
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 ? With EFI instead of BIOS, so very helpful for DOS USB support ??? These are representative statistics, of course. Link please. Otherwise I'll stay with existing hard facts: - From 6 PC's I tested all 6 failed (2 attempted and failed, 4 didn't even try) - There are 1.6 guys reporting to have it working ;-) From what time are your 6 PCs? Any 2004+ mainstream PC I've seen contains a BIOS version which I know supports booting from USB (since I tested these BIOS versions on some PCs). BTW, no 2004+ mainstream PC I've seen (except x86 Macs) contains EFI. Some of the BIOSes require the boot media to be formatted with MBR (as that HP bootable flash format tool creates) but some require super-floppy format instead (no MBR, a single partition). Or exactly: Current DOS versions require this, the BIOS just provides the storage as either Int13 disk *below* 80h (floppy) or *above*(/equal) 80h (hard disk with MBR), and since now I've seen no DOS version to provide any kind of auto-detection, or a manual override to disable/enable the partition table parsing for the boot drive no matter which Int13 unit it is. (Guess to what DOS version I'll add at least the override option ;-D ) Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A windows 9x replacement...
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. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A windows 9x replacement...
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? -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A windows 9x replacement...
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 from what point of view? They were sold as OS (what they aren't either) back then ... Yes, but everyone technically experienced could tell they weren't and aren't. (Windows 9x arguably tries more to work without DOS, but if it would have been a stand-alone operating system, why boot it from DOS? Because of the compatibility and to give customers a free MS-DOS with the new shiny Windows? You don't say.) Japheth writes on his site that HX's source code is about 100,000 lines of code When in doubt download it and recount :-D Sorry, my little (C) program to automatically count lines only works with NASM source code ;-) Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] UIDE.SYS
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 it's size on disk. and a driver similar in size to a ramdisk. No. I haven't asked for adding block-device to UIDE, just non-BIOS disks support... Support means you access them somehow - just adding them to int 13 will not give them drive letters, only lowlevel access. Although it is *obvious* at this time, why not use Int2F.0801 (Add new block device [to the default DOS block device driver]) to add the drives after enabling the Int13 access? The only notice here is that some DOS versions use varying layouts (i.e. MS-DOS 7.10+ with FAT32 EBPBs, and I hope FreeDOS with FAT32 uses the same layout) so such a feature would have to be configured carefully for different versions and code is required to tell them apart. After all, that installation code (which leaves only the actual UPB (DDT) in memory) could easily be moved into another program. It could use a specific UIDE backdoor (or access UIDE's data, or do something else) to get to know which Int13 units are provided by UIDE exclusively; or a generic API could be written which could also process added Int13 drives provided by different drivers. Then the installation program would read from the provided unit to decide whether the first sector is the MBR, or a partition boot sector. It would parse the MBR (if any) and then add block devices for each DOS partition. Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A windows 9x replacement...
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 programs as well. Freedos doesn't need to be munged to do those things that MS-DOS did that don't make sense. I don't see where it currently does any such things, even in the WINKERN version. Sharing the System File Tables with all other virtual machines (DOS boxes) makes perfect sense because the DOS file I/O needs to be serialized anyway. Need I remind people, you cannot legally run MS-DOS anymore. Get an old MS-DOS or Win9x license and you have your MS-DOS to run legally. It's not something you can legally install to a system that never had MS-DOS. Uhm, why not? Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A windows 9x replacement...
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 would just need someone willing to write the user apps included in Windows 3.11. Either I've missed that HX now supports loading all Windows VxD drivers, or it still doesn't. Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A windows 9x replacement...
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 of the Windows 9x line (and it's the best version of Windows 9x, except dropped DOS mode support). I agree here. A new GUI should not run exclusively on FreeDOS, because that's the Microsoft approach. Ideally, all programs should run on MS-DOS (or DR-DOS FreeDOS + EDR-DOS + RxDOS + ... And create a DOS GUI, rather than a ME or NE clone ... And Windows 3.x/9x is no DOS GUI from what point of view? I would recommend to program your GUI in a way which makes in run on any DOS, using exclusively normal int 21 calls for which you can easily get documentation by reading a MSD INT $21 doesn't provide any GUI ... so you will need VESA + VGA BIOS (+ VGA ports) or VGA + PCI ports + some mouse support (INT $33 is unusable, so a new mouse driver standard) Int21 doesn't provide any multitasking and file sharing stuff or patching of the system to do certain things like writing (virtual) machine IDs into SFTs. All found on Int2F, readily usable if you plan on writing either a Windows replacement (use 2F.16, 2F.1605 as call-out) or a generic multitasker (use 2F.16 except the call-out, there use a 2F.4B multitasker instead because you can't load Windows VxDs) for MS-DOS 5+. Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A windows 9x replacement...
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 lines (with 10,000 lines of that being only comments, assembler directives, blocks commented out with #IFDEF (NASM %IF) and such). So, ignoring which is more difficult to write, a full Windows replacement will certainly take much more work, just for the typing! And FreeDOS's kernel has been in development for much longer than 2 or 3 years and still isn't 100% compatible to MS-DOS. Because that's not the goal of the kernel. Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A windows 9x replacement...
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 separate project. I agree here. A new GUI should not run exclusively on FreeDOS, because that's the Microsoft approach. Ideally, all programs should run on MS-DOS (or DR-DOS or...) as well, or failing that there should exist an adjusted version or a driver that makes the program work on the other DOS versions. I think asking the FreeDOS (kernel) developers to provide technical information about DOS, while not tying the program to FreeDOS specifics, would be most useful to achieve this. Speaking of a Windows replacement, it could be handy to use some of the Windows (3.x) support already embedded into MS-DOS (this is all undocumented by Microsoft, but became documented undocumented by UDOS, RBIL and other sources). Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Basic sound access in DOS.
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 great deal of usability to dos apps, especially ones that already work directly with sb compatible cards. The problem is that apps working with SB cards usually do this by accessing hardware ports directly (in/out instructions). You can't hook ports as easily as interrupts, so a driver which would provide other sound cards to work as SB would require protected mode. It has been suggested to write the driver as Jemm Loadable Module (JLM) to do this. This could only be loaded by the Jemm386 memory manager. Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Basic sound access in DOS.
[...] 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 the previous mail. Regarding sound libraries for new apps, I heard there are some around. Maybe someone else can recommend you some of these. Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] jam
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 represented in 16bit clusters... FAT32 aware kernels (says the RBIL) do not keep a 16bit cluster number in the SFT even for files on FAT16 disks. Where does the RBIL say that these kernels don't set it for FAT16 disks as well? Ok, it's true, but I had to verify it on my machine because RBIL doesn't state this clearly. Anyway, I think it won't hurt FAT32 DOS programs that much if DOS would actually provide the starting cluster in the SFT for FAT16 drives only. JAM.DOC about the DOS OEM/version problem: Incorrect DOS OEM number. Origin JAM.SYS Explanation Your computer has a DOS with uncommon OEM number. JAM device driver accepts any MS-DOS-compatible Operating Systems with version 3.30-7.0 and with the following OEM signatures: 00h - IBM 01h - Compaq 0Dh - Packard-Bell 0FFh - Microsoft If you have received this message, you should contact us for upgrade information. Did anyone try to contact them already? Even if they don't want to release the program or its source for free, maybe they could update it so that it would work with FAT16 drives on FAT32-aware kernels? (Or even with FAT32 drives, but I assume that would take more work.) Regards, Christian -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] jam
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 directly. This will definitively not work if the host drive is FAT32, but might even cause problems only because the DOS version supports FAT32 at all. A FAT16-only FreeDOS kernel binary might fix the problem. Regards, Christian -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Windows 3.1 - Pending kernel 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 included in FreeDOS 1.0 as well. The current build is 38 Stable, which is currently based on 36 only. The final 38 release isn't done yet so you can't use this version unless you can compile it yourself or download a snapshot binary from somewhere else (like Rugxulo's pages). Regards, Christian -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Windows 3.1 - Pending kernel patches
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, of which two are already provided in source form. He doesn't exactly have to wait for these, we've completely described them. This sounds strange to me. As you both probably know, the unstable branch was discussed not long ago and it was made clear that it was not ready to be released. Three more necessary patches doesn't really help, does it? The unstable branch can become a big treasure for future development, but why release unstable binary for testing when noone is developing it? A list of all the patches is being made. The pending patches are in no way associated with the so-called unstable kernel fork. As mentioned in my list below the mail, at least two of them have to be applied to unstable as well, if anyone wants to continue its development. You can't argue that the patches are to be applied to an unstable version of the kernel _only_, because anyone with enough understanding of C (first and last patch) or Assembly (second patch) will understand that these patches are necessary, that they properly fix critical bugs, and that there is no chance that they might break anything related to compatibility. It's the opposite: Some things will work that didn't, e.g. accessing files up to 4 GiB size on FAT32 drives. Or using the ESCAPE program that lead to the bug report the first patch will fix. If you think I'm wrong here and that this is somehow related to technical kernel stuff, please respond on the Freedos-kernel list instead. Regards, Christian -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Detect ramdrives Fwd: [basic-es] Hola, una pregunta
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 to check if the unit is a real disk or a ram virtual disk? i use FINDRAMD.EXE from this site: http://www-user.tu-chemnitz.de/~heha/hs_freeware/freew.html source code included. It's rather unreliable because it only checks whether there's just one FAT on the drive. However, that _is_ the most reliable method of detecting a RAM disk because there's nothing else different RAM disks have in common. Expect that some non-RAM disks might also be detected this way. Obtaining the drive letter from the RAM disk's driver or asking the user is the only certain way. Regards, Christian -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] was: Windows 3.1 - Pending kernel patches 2037/2038
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 sourceforge in our svn, of course :-) If there's a stable 2038, then that should get put on ibiblio for general release as soon as possible. If it's on rugxulo's pages, then very few people will know about it (heck, *I* didn't know about it - see my other email.) 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, of which two are already provided in source form. He doesn't exactly have to wait for these, we've completely described them. (The first one on the list, others in the FreeDOS bugtracker or old private e-mails.) Since it seems Eric doesn't exactly want to be the kernel maintainer, you need someone else for that. The mentioned patches are: - Terminating self-owning PSPs (parent PSP field set to the PSP) doesn't work. There's a patch for this in inthndlr.c but it's wrong and leads to crashes. The patch in inthndlr.c (below case 0x4c of the main Int21 handler) has to be removed, and the condition of a self-owning PSP has to be handled like a TSR termination in the return_user function in task.c. 2037 is affected by this, too. - CALL 5 interface is broken, and probably crashes the system. The Assembly code in entry.asm that handles such calls is screwed up. I can provide working replacement code or patch it to work how it's supposed to. 2037 is affected by this, too. - The seek position (and various other fields) of the SFT isn't declared as unsigned. Eric reported that the seek function reports errors using negative return values. This has to be changed so that it can work with files up to 4 GiB. Depending on when the seek function is called (whether it's already determined that the handle references a valid SFT, and that the origin in al is valid) you might just remove any error reporting of it, since the actual seek operation never returns errors in MS-DOS (as mentioned in RBIL and UDOS too). 2037 seems not to be affected by this, at least the case 0x42 in inthndlr.c should work with larger seek positions. I've CCed the Freedos-kernel list, too. Regards, Christian -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] was: Windows 3.1 - Pending kernel patches 2037/2038
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 Edition, p.15) and doesn't really influence the performance of Windows even if it's used. Plus it replaces parts of DOS while running. (Either for underhanded as the book hints at or legitimate concerns it doesn't matter at this point) This probably some of the reason for the problems. Win 3.x will probably never be 100% on FreeDos, nor will a compatible Win 3.x GUI ever be 100%. Some sites suggest to switch off the 32-bit disk access and 32-bit file access (if the used Windows version supports either) because they conflict with larger or newer disks and FAT32. Some other SYSTEM.INI settings regarding DOS critical section handling and stuff might also be useful to setup a stable Windows configuration for a non-MS DOS. I have been looking and asking questions on both of the Wine and ReactOS forums and it looks promising. I think I will buy a copy of windows 3.x on EBay and use that for comparison. I can barely remember what it looked like and what is all there. LOL I was thinking of calling the GUI Janus after the code name for windows 3.11. Which I think should be ok legalwise. Thoughts? Sounds good. The lack of license for HX DOS Extender concerns me a bit as well. If code is posted with no license can it be considered public domain? I emailed the author but have not gotten a response. Well, it's called freeware (including the source code). I think you can use it for anything, but wait for someone else to answer this. Also I remember from my pre dot net days using a program which would inspect a dll and identify all the public methods/functions that it has. Would this be considered legal? If so anyone remember what that program is/was? I used it at a client site to integrate with a 3rd party DLL and application. Since disassembling MS-DOS is considered legal by UDOS and RBIL authors (and these sources are considered legal by all members of the FreeDOS project) I think there's no problem using some DLL examination tool. Regards, Christian -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] WAS Re: [Freedosuser] FreeDOS localisation project = 2038 issue?
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 two-digit years which creates the year 2079 problem: 80..99 is interpreted as 1980..1999, and 00..79 is interpreted as 2000..2079, however I can't find evidence that DOS itself is affected by this. Regards, Christian -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Installing programs on FreeDOS v1.1
- 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!). Regards, Christian -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] network drive
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 network redirectors for FreeDOS? Making this thing run in the background might be a bit hard, I remember that it did not even report any idle times to FDAPM... You should read the RBIL documentation about int 2f functions 11nn which are network redirector. The kernel automatically uses those functions for network drives which support it. Umm, yes it does after you modified a drive's CDS to show that it's a redirected drive. So get familiar with some of the data described at Int21.52 (MS-DOS 4+ CDS and SFT, MS-DOS 5+ List of Lists) and some of the Int2F.12 functions, too. The free SHSUCDX source contains all of this (although it doesn't provide write access to its CD-ROMs). It's written in Assembly, but unless you want to use some weird C stuff (that essentially emulates Assembly) you have to use Assembly code to service the DOS calls anyway. Regards, Christian -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] network drive
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 kernel.asm and entry.asm in DOS-C. I didn't express it right. -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] aimed compatibility?
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 FAT32, but I do not think that we want to be very Just a bit compatible? MS Win98 DOS 7 compatible as this DOS was not even meant to run DOS apps anyway. It was. As Microsoft had shown with MS-DOS 8 they were able to (and did) disable the DOS mode of Windows 4.x later. So MS-DOS 7 (both versions) were meant to run DOS software. Why does this question matter, anyway? Late DOS apps were written with FAT32 and/or LFN support aimed exactly at MS-DOS 7. The authors probably didn't care whether this MS-DOS was intended to be DOS. It worked well being exactly this. So if you ask me: Our current goal is compatibility with MS DOS 5 / 6 kernel in the general case and a nice collection of apps similar to MS DOS 6... Plus support for new hardware in ways which may (FAT32, LBA) but do not need to be compatible to Win DOS 7. Might be coincidence that the DPB layout of MS-DOS 7 and FAT32 DOS-C is the same. Or that the same new, complicated FAT32 Int21 functions are supported. Or that DOSLFN services exactly the LFN functions used by MS-DOS 7 COMMAND.COM versions. Regards, Christian -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] LFN in FreeDOS kernel? - was: aimed compatibility?
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 format. Only because NTFSDOS doesn't (didn't) translate NTFS original LFNs (that were stored without SFNs) to accessible SFNs. Refer to how DOSLFN does this for CDFS filenames that are too long, so it is indeed possible. (Might be more difficult with NTFSDOS Professional's R/W access though.) and Many people believe that MS-DOS doesn’t support long file names at all, but that isn’t the case. It is the MS-DOS FAT file system driver that lacks support, rather than MS-DOS itself. If you prefer to refer to the kernel as the MS-DOS FAT file system driver only, that's true. (So that MS-DOS itself here means all other programs.) Else it isn't true, because the kernel doesn't contain any LFN support at all, and it is in fact made up of more than a FAT driver. Regarding this you have to remember the redirector interface, too. When used with a file system that supports long file names MS-DOS handles them fine, The kernel doesn't care. as do MS-DOS applications that are written to take advantage of the support. What they tell you is that NTFSDOS horribly hacks into Int21 to provide the LFN services on it's own. Because the redirector interface (which is else used by NTFSDOS) was never updated to provide LFN services. It must be a horrible hack because the redirector was designed so that the driver (here NTFSDOS) doesn't have to hack into Int21 and provide any direct Int21 services by itself. Author was Mark Russinovich / Bryce Cogswell so I believe the statement was correct. They were supposedly Windows experts, weren't they? What about FreeDOS kernel and LFN? Wouldn't it make sense also to add LFN to the FreeDOS kernel? If someone has enough time for this.. Also according to http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/index.php?n=Main.Compatibility it also seams doslfn is not the answer and needs bugchecking by a third developer. Someone able to do this? For sure, if LFN goes into the FreeDOS kernel it would make much sense to add also LFN support to the FAT driver. Is this already the case? For sure, if LFN services would be added to Int21 only but not the filesystem driver(s) it would be a complete waste of effort. DOS-C's FAT driver is probably LFN-aware (shows correct volume label even with LFNs etc.) but doesn't contain more support. [There's however this LFN helper API but I don't know what it's supposed to do and there's no documentation.] Regards, Christian -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] aimed compatibility?
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
Yes. I noted that in my first reply of this thread.
if YOU think LFN support in the kernel would be interesting, sit down
and make it. everybody else will have to use DOSLFN...
To whom in particular did you write this? I'm of your opinion, too.
I would call that 'hard work', noy just 'coincidence' ;)
Yes. Yes, it was work. Work to make FreeDOS compatible with MS-DOS 7
(Eric's so-called Win DOS). Contrary to Eric's statement it seems that
it needed to be compatible; or why else would you work for it?
EA:
Plus support for new hardware in ways which may (FAT32,
LBA) but do not need to be compatible to Win DOS 7.
Regards,
Christian
--
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] aimed compatibility?
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 FreeDOS mostly aims to be compatible to 7.10. This does not include Windows compatibility. Regarding Windows 3.x FreeDOS (with unstable kernel) tries to be either 6.22 or 7.10 or (with stable kernel) a mix of 3.xx and either 6.22 or 7.10, which seems to work not so well. Windows 4.x doesn't run on FreeDOS. Regards, Christian -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS silently writes to partition table?
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.bin2250 499 2502008125 82 Linux swap / Solaris gut.bin3 *500+ 4677- 4178- 335544327 HPFS/NTFS gut.bin4 4677+ 19456 14780- 118716768+ 5 Extended The Extended partition contains another 4 partitions, 2 Linux ext3fs, 1 NTFS, and one FAT32 (the very last one). Table after booting FreeDOS: Device Boot Start End #cyls#blocks Id System schl.bin1 * 0+249 250- 2008093+ 6 FAT16 schl.bin2250 499 2502008125 92 Unknown schl.bin3500+ 4677- 4178- 33554432 17 Hidden HPFS/NTFS schl.bin4 4677+ 19456 14780- 118716768+ 15 Unknown Note how the first partition changed from HIDDEN FAT16 to NORMAL FAT16 and the active partition changed from NTFS to FAT16. The change from 5 to 15 is from CHS extended to LBA extended, you just used a very old software to display your partition table. No it didn't. The Id values are apparently hexadecimal (notice 17/7 for hidden NTFS/NTFS, 16/6 for hidden FAT16/FAT16). The (CHS) extended partition changed to the type 15h, or hidden extended, which doesn't exist for most software. I also think that this hiding / un- hiding and change of the active partition is actually some thing that your GRUB configuration caused ;-). Although it sounds strange if GRUB itself can't use the hidden extended partition, I would also suspect this is done by GRUB, not FreeDOS. I think there's actually no code in FreeDOS (kernel) to write to the partition table, and if it was written by accident, it would have changed more than just this one byte (actually, this one bit). Possibly a bug in GRUB? Because, well, GRUB does write to the partition table anyway. Regards, Christian (M.) -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS
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 [NEW]. What was the effect? Got the bug changed from [NEW] to [CONFIRMED]? Is it now on some developer's todo list for fixing? I am not convinced that this bug will be gone in future. It'll be gone, as soon as someone delivers the fix to DOS-C's SVN. [Because official DOS-C builds aren't released often enough, like below one year between builds, you'll then have to download the newest kernel from Rugxulo or compile it yourself.] I'm however not a registered developer of the SF.net project, and I don't know how to or like patching with SVN or such anyway. It'll be fixed as soon as one of the developers feels to commit it. We are just involved in a lot offtopic and principle discussion. And you're always feeding this off-topic discussions with more unnecessary things to talk about. Like Coreboot or some special hardware they need for testing something. Regards, Christian -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] [BUG] FreeDOS not compatible with escape [NEW]
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 possible. Could you please test whether aborting some other application (no COMMAND.COM type program) works in FreeDOS? Yes, first he application will be terminated and then also the command interpreter which results in the same bug. Well this shouldn't happen (and won't be fixed by the bugfix in my previous mail), it should only abort the application. Are you sure you pressed F12 only one time? Regards, Christian -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] [BUG] FreeDOS not compatible with escape [NEW]
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 complicated batch scripts (file extension .BAT) written for MS-DOS, but it's easier to write new batch scripts. It also has a nice user interface, the embedded help program describes the available features well. FreeCOM is still the standard, basic CLI of FreeDOS (so expect it to be available on most FreeDOS installations) but it seems many users now prefer 4DOS (which is free as well now). You may ask Lucho (the maintainer of 4DOS and that website) for more information about 4DOS, or some of the other guys on this mailing list for more information about FreeCOM. and are there differences between http://sourceforge.net/forum/forum.php?forum_id=930832 and http://4dos.zzl.org/ No, the first page contains just a message of the FreeDOS project's news. This message refers to the same 4DOS program found on the second page. Next time please start a new discussion if you want to ask a question that doesn't belong to an existing discussion. Starting a discussion is done by sending a new e-mail to the freedos-user address instead of replying to an existing message. Regards, Christian -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] unload previsiously loaded exe and sys on fdconfig.sys
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. If you have to use a program without such an option you may want to try out the TSR Utilities (freeware without source code) which save some important system data before you install the program, then try to unload the program later by restoring this data. This method doesn't work for all programs so you have to be careful with it. I think the TSR Utilities don't work with programs loaded in FDCONFIG.SYS but you could try whether that program can be loaded by DEVLOAD (on Eric's site, or on the FreeDOS software page) instead. Regards, Christian -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
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 boot disk image.) ...embedded requires major code re-writing for this new kernel, instead of relying on working FAT drive support (which only requires the kernel to access a boot time ramdisk, typically some int 13 based ramdisk). I think accessing file contents from RAM is easier than writing a small ISO 9660 driver. Well, just add support for the well known drive letters [\]^_` into the kernel and that's it ;-) We already have SOME 32 drive awareness, but as I did not know that they are called [ \ ] ^ _ ' I never tested them. Note that the last is not ' (single quote) but ` (some sort of accent). Just look at ASCII character set listings, they show these characters right behind the capital letters. Nor do I know whether our command.com etc would allow me to type them. Yes, application software usually has to be aware of these drive letters. (Displaying the drive might still work if the application just gets the drive number and adds the value for ASCII 'A'.) Maybe you can do some experiments and find out which parts need adjustment. Note that \ should not be used, conflict with UNC. No. If you're accessing something that starts with \:, the backslash is clearly used as drive letter. or waste time of the new-tool-writers. Don't we waste time anyway? Yes, but the topic is too much fun to talk about ;-) I see your point :-) There are also tools to create message files. They, too, are easier to use and install than the complex compile environment needed for command.com :-). Is it complex compared to the message file creator or complex compared to other compile environments? You basically have a textfile with messages and then run 1-2 commands like makemessagelibrary in.txt out.xyz and maybe compressmessages in.xyz out.abc, I do not remember exactly. No, I meant is the compile environment needed to compile command.com more complex than compile environments needed for other (DOS) software? Well you can spend your own time on the project but do not complain if it takes long or introduces new problems ;-). If it introduces problems they'll often be solutions for these problems as well. (Or you just avoid problems, which isn't difficult at boot time because you don't have to be MS-DOS compatible then.) As said - depends on how much time you want to spend. And you do have to be compatible at the moment when you start loading drivers in config.sys, some other data structures even have to be filled in earlier than that. Yes, but the first relocation of the kernel data and code is done when there's no CONFIG and DOS isn't even available. So it doesn't have to be compatible. Well, being DOS doesn't seem to include organizing memory in a chain of MCBs as DOS in MS-DOS pre-CONFIG/CONFIG time. As shown by the recent tests with Debug there is only one MCB containing all low memory. If it's the same in DOS-C (I doubt it is) SHSUCDX couldn't load. Exactly - running EXE/COM files is not possible before the INSTALL and SHELL phase, That's how it might be currently. However I think you could change the pre-INSTALL phase to be compatible enough for executing SHSUCDX, while still being compatible to MS-DOS device drivers later. while running SYS files is usually done earlier. Tools like DEVLOAD can run SYS files later, at the cost of having to repair patch, extend? some structures and not being able to load early drivers as HIMEM / EMM386 fully: You can DEVLOAD them but DOS ignores some features then. If you knew the location where DOS stores the first UMB's address and such stuff you could later patch DOS to add UMBs; which you've allocated from the XMS driver of course. (I think MS-DOS 5.00+ stores this data in the buffer info record which is pointed to by a List of Lists entry, see RBIL Int21.52.) Moving the DOS code to the HMA is of course more complicated. (Read: I don't know how to do this in MS-DOS.) Regards, Christian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
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 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 boot disk image.) maybe using NO typeable drive letter: If the kernel detects it is booted from CD/DVD, it would use a letter after Z (you can have 32 drives) for that special driver and set the current drive to that, so you can use DEVICE=ELTORITO.SYS and INSTALL=SHSUCDX without having to mention drives or directories... Well, just add support for the well known drive letters [\]^_` into the kernel and that's it ;-) That need not be hard... You could for example say that the 2nd file has to start with MZ (shsucdx.exe and any other exe)... After all, the whole theory is very specialized towards eltorito/shsucdx anyway and eltorito.sys happens to have no misleading MZs inside either ;-). Sounds fun but isn't really reliable. Another ELTORITO.SYS version could easily include such a misleading MZ. Future versions of SHSUCDX (you said 6 KiB?) could easily be assembled into a .COM executable as well. Writing new tools or modifying UPX for only one single file will only annoy UPX developers You could release it as fork (or patch) if they don't want to include it in their distribution. or waste time of the new-tool-writers. Don't we waste time anyway? Even if you did it with copy /B ... and then the UPX hack, won't it be easier for the user to use the build script to compile a new kernel which incbins the files instead of using copy /B and UPX manually? No. Another example is FreeCOM: You have a translation-friendly command.com binary blob which you COPY /B before a message file in your language and voila you have the complete command.com in the language of your choice :-). Yes, but that appends only one file. Appending two files to the kernel raises the need to find where the second file begins. (If possible without unreliable signature searchs.) There are also tools to create message files. They, too, are easier to use and install than the complex compile environment needed for command.com :-). Is it complex compared to the message file creator or complex compared to other compile environments? But as said, I prefer not to put raw files in the kernel at all. C design limitation? ;-) No, just a bad idea in general. And very incompatible because you will have no useful information about the (nonexisting) filesystem from which those files would magically emerge for use by the kernel which still uses and IS DOS. I strongly prefer existing filesystems. You load these files once. I see no need to create a filesystem through which you could access these after booting. Correct, kernel_start cannot copy more than 128 kB yet but as always deep inside the kernel memory model and startup code, structure is complicated and adding more areas such as embedded files would make things a lot more complicated. If you say so. I rather think when you already added support for 128 KiB data moving (requires accessing the data from two segments), more can't be that difficult. Well you can spend your own time on the project but do not complain if it takes long or introduces new problems ;-). If it introduces problems they'll often be solutions for these problems as well. (Or you just avoid problems, which isn't difficult at boot time because you don't have to be MS-DOS compatible then.) This would require the kernel to be compatible enough to post-CONFIG state when only pre-CONFIG I would not call this compatible, rather incompatible. Well, then someone would (!) need to *make* it compatible. DOS doesn't have to be incompatible to post-CONFIG. Because pre-CONFIG is so unknown no one even cares whether DOS is incompatible there. Drivers do care about DOS already being DOS when you run the DEVICE lines. And DOS cares about already being DOS when it tries to set up devices and run DEVICE lines, too. Well, being DOS doesn't seem to include organizing memory in a chain of MCBs as DOS in MS-DOS pre-CONFIG/CONFIG time. As shown by the recent tests with Debug there is only one MCB containing all low memory. If it's the same in DOS-C (I doubt it is) SHSUCDX couldn't load. Despite this, DEVICE= is executed during CONFIG time instead of pre-CONFIG. You are of course also welcome to spend time helping to solve mainstream problems at the same time, even if those seem so normal, boring and non-interesting to you that you fall asleep instantly when reading about normal problems ;-). In DOS no problem is normal ;-) But feel free to politely ask Bart of nu2.nu
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
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 letter) No. You could just load the contents of the files and execute them so you don't have to provide a letter. as well as extra tools to generate such a kernel with diskimage combined file in the first place. Well, when not using the disk image approach the kernel would have to know the exact position of the files anyway. You could just include the binaries in a NASM source file (think with incbin) and let NASM declare the position as global label. (Yes I know there are workarounds to create unsigned char arrays with hexadecimal values that represent the data in a C file but NASM's incbin is easier to use and doesn't fill source files with redundant data.) Note that our boot sector already can boot 64k kernels. If the kernel doesn't relocate itself later that's fine. If it does, the relocation code also has to handle 64 KiB. Also note that SHSUCDX is not meant to load from config sys, you are supposed to load it after all device=X even though you probably can load it before autoexec bat, by using some install=... line for SHSUCDX. Yes. SHSUCDX is documented to work with INSTALL= (or INSTALLLAST= if available), but may not work when loaded as with INSTALL= but before processing CONFIG.SYS (and device drivers despite the embedded ELTORITO.SYS). CONFIG.SYS would (if not on an embedded disk image) be found on the CD-ROM so you would have to load both the driver and redirector before you can access the file. This would require the kernel to be compatible enough to post-CONFIG state when only pre-CONFIG, and possibly some special version of SHSUCDX. (I would try to avoid modifying SHSUCDX.) It would also require the CONFIG.SYS parser to skip CDS entries used by redirectors, because SHSUCDX is a redirector and it would be loaded before CONFIG.SYS (that's the same problem DEVLOAD currently has). Both driver and redirector would have to stay in low memory unless you also embedd XMM and EMM in the kernel/include it on the embedded disk image, or write some special code to relocate the driver (have to fix up pointers in SHSUCDX internal data, and the DOS device chain) and SHSUCDX resident part (have to fix up Int2F). Relocating SHSUCDX could also be done by preserving Int2F with another hook, and when UMBs are available, restore Int2F to SHSUCDX's temporarily, uninstall SHSUCDX, restore Int2F to actual chain (which doesn't include SHSUCDX anymore), and then re-install SHSUCDX into a UMB. This would also make relocation of ELTORITO.SYS easier because you won't have to fix up data in SHSUCDX during the time it isn't loaded. Well, if that all makes such problems, what's the point of not using an embedded disk image with the driver, redirector, XMM, EMM and CONFIG.SYS on it? Because the user would have to modify the kernel file containing the disk image each time CONFIG.SYS is to be modified or to use another XMM and EMM. (Though updating the driver and redirector would require recompilation/modifying the disk image in either case.) Why is the source code (of eltorito.sys) not available? If you'd really need it badly someone could disassemble it. That would not be polite. It is not available because Bart of nu2.nu did not have the impression that the work for making it available would be worth it, given the apparently few people who have asked him yet :-) Aww. What a polite guy. Regards, Christian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] variable for boot device?
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 but I don't really like to. You have to. SET /E uses a temporary file for the output of the command, just as pipes do. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] generic bootsector as file? - versatility of grub4dos explained
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 become a developer of DOS-C (FreeDOS kernel) because it's design is to be written in C where possible which I think is a bad decision (Japheth probably agrees here). Besides, I'm too egoistic to write or re-write major parts of something when this new version isn't accepted because it isn't tested enough. That was the case with the unstable DOS-C version 2037 (which had many features version 2036 and the upcoming 2038 don't have). But he DOES contribute to FreeDOS: Who is he?? Me. once the few remaining bugs are fixed in the RxDOS kernel, it will replace the inferior current FD kernel. That's a nice point of view but you'll have to wait until it's done. To speak about few remaining bugs doesn't match the reality. Another caveat is that once might have to wait another few months or year. I tested a lot RxDOS and was very frustrated becuse: 1) it was very good and very compatible Doesn't match my experience. (Well, you probably tested it another way as I did.) 2) it had very few bugd (iirc only 3) 3) the bugs were *very* bad, I just don't remember exactly but completely incapacitating Yes they're quite some bad bugs. Some of these are in RxDOS's COMMAND.COM replacement RxDOSCMD (or, as I call it now, RxCMD) which I will probably fix too. 4) the programer was the author of Undocumented DOS Michael Podanoffsky, the best book around, but he just vanished (abandoned?) Errm, nope. I think Mike did contribute to Undocumented DOS (you can ask him by e-mail), but his own book was Dissected DOS. It concentrates on the RxDOS 6.00 source instead of showing disassembled MS-DOS code. Of course I've both books on hand here. 5) it was just MS-DOS 6.22, and now FreeDOS has many important things, one being FAT32 which I cannot live without. True for RxDOS 6.00 (shown in Dissecting DOS) but not for RxDOS 7.x. The newer RxDOS releases have FAT32 (just as DOS-C) plus LFN functions *inside the kernel*. That is you shouldn't need DOSLFN to use LFNs. However both features will often not work as expected because they're slightly buggy and incompatible. One of my goals is to improve this. Regards, Christian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Sound
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. A DOS sound driver would have to intercept some ports provided by real SB cards. This requires either a EMM or full protected mode management inside the driver. (I guess using the EMM is less work.) -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MBR source code
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 -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Licensing (comp, printq)
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 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Loading old DOS programs under FreeDOS
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 error. Christian -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
