[Freedos-devel] Fwd: FreeDOS has an error with it's DEVICE= line in CONFIG.SYS
Small bug report (and several comments) on news://comp.os.msdos.programmer , if anyone is curious. https://groups.google.com/forum/?fromgroups=#!topic/comp.os.msdos.programmer/mxAPSdUML7U I pasted this DEVICE= line from my MS-DOS CONFIG.SYS into FreeDOS' CONFIG.SYS (v1.1): DEVICE=HIMEMX.EXE/MAX=2097152/NUMHANDLES=128/METHOD:PORT92 It flagged the '=' sign with an error via a caret '^' on the next line. What does that mean exactly? What could be wrong with the '=' sign? Nothing. It happens there is no correlation between the indicated error and the problem ... There is a bug in FreeDOS. So, next, I reduced the FreeDOS DEVICE= line to: DEVICE=HIMEMX.EXE It still flagged the '=' sign as an error. After spending a half-hour trying every combination of upper- and lower-case DEVICE=, HIMEMX.EXE, and the path, I found that FreeDOS needs a space between HIMEMX.EXE and it's parameters. Unfortunately, the need for a space is required whether the DEVICE= line has parameters or not ... I.e., the line above without parameters needs a space at the end!!! Most DOS editors trim the final spaces from the end-of-line. I'd think that anyone familiar with DOS would know that or should. If you're reading and are familiar with someone on the FreeDOS team, could you pass along this error report? Rod Pemberton -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: FreeDOS has an error with it's DEVICE= line in CONFIG.SYS
Op 17-12-2012 22:35, Rugxulo schreef: Small bug report (and several comments) on news://comp.os.msdos.programmer , if anyone is curious. https://groups.google.com/forum/?fromgroups=#!topic/comp.os.msdos.programmer/mxAPSdUML7U I pasted this DEVICE= line from my MS-DOS CONFIG.SYS into FreeDOS' CONFIG.SYS (v1.1): DEVICE=HIMEMX.EXE/MAX=2097152/NUMHANDLES=128/METHOD:PORT92 That might be worth looking into, likely requiring Metakern chaining to both MSDOS and FreeDOS kernel 2041, with both using the same config.sys file. (Lack of) spaces is a nice challenge for the (fd)config.sys parser algorythm anyway (and occasionally FreeCOM also) : SET /MEMDISK=1 (sees as invalid option, MDISKCHK causes this) SET X = Y (happily adds spaces, making value checking a nightmare) Bernd -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Fwd: [Freedos-user] USB Driver Comparison
Hi, Forwarding here, in case someone didn't do it already (Gmail didn't pick any reply to this, did anyone else comment on it?). Aitor -- Forwarded message -- From: Bret Johnson bretj...@juno.com Date: 2009/7/24 Subject: [Freedos-user] USB Driver Comparison To: freedos-u...@lists.sourceforge.net There has been some discussion lately on the FreeDOS mailing list about the comparison between the DOS USB drivers made by me (Bret Johnson, http://bretjohnson.us), and those made by Georg Potthast (http://georgpotthast.de/usb). The discussion has been around three major points, and I would like to comment about those points from my perspective. 1) The licensing arrangements. The licensing arrangements for my programs are stated pretty clearly on page 6 (the Copyrighted Freeware section) of USBINTRO.DOC. The license is not simply a copy of some other canned license (GPL, Artistic License, etc.), and never will be. Rather than inserting a bunch of legal jargon for lawyers to fight over, I simply state my intent. Read it and see if you still have questions. 2) The possibility of placing a wrapper around one or both of the drivers so that in the end they have the same API, and the user will have a choice as to which one they use. At a very basic level, the two architectures are completely different from each other and incompatible. The difference is so fundamental that it actually goes right over most people's heads, and they don't grasp what it really means. A quote from Georg's documentation: Using the URB you can only schedule a transaction to a single device specified by the device address. So you can send and receive data from a mass storage device or send data to a printer. If you have a camera, which sends a constant stream of data or a mouse, DosUSB will not be able to retrieve that data while it is executing a transaction to e.g. a printer. In other words, Georg's architecture allows only one thing to happen at a time. For example, under Georg's architecture, it would be impossible to be listening to some background music from a USB-attached CR-ROM, playing on a USB-attached sound system, while typing on a USB-attached keyboard at the DOS command prompt. It would also be impossible, for example, to be using Arachne to access browse the internet across a USB-to-Ethernet converter, while using a USB-attached keyboard and a USB-attached mouse to control the Arachne program. Of course, all of these things are possible in today's world when you're not using USB, and should be possible when you start using USB hardware as well. Now a quote from my documentation: These DOS USB Drivers are specifically designed to be run in the background. That is, when you tell the Driver to send some data to a particular Logical Device, the Driver essentially says, OK -- now go do something else and I'll let you know when it's done. The Driver takes care of sending the data ENTIRELY in the background, while the computer is busy doing other things in the foreground. As you might imagine, running a process in the background is much more complicated (requires more memory) than doing it in the foreground. However, the advantages it provides (such as the ability to support mice and keyboards) generally makes it worth the extra complexity. In addition, a background process can very easily simulate a foreground process in situations where that is required, while it is impossible for a foreground process to simulate a background process. The examples stated above are all completely possible under my architecture, even though drivers for USB CD-ROMs, sound systems, and USB-to-Ethernet converters have not been written yet. The point is, under Georg's architecture, it is impossible to write drivers that could do all of those things, and do them AT THE SAME TIME. It's also impossible under Georg's architecture to implement plug-and-play. There are also very fundamental differences in the API's. Georg's API is limited to scheduling packets across the USB bus (what he calls a URB, or USB Request Block). My API allows almost complete management of the bus, not simply the scheduling of packets. In fact, it would be possible to build an application (even a GUI) that almost completely monitored and controlled the USB busses and all the USB devices attached thereto, using only calls to the API. I should point out that I have no intention of writing such an application, but somebody else certainly could. 3) The code is complicated and hard to understand. Of course it's complicated. A host driver is capable of managing dozens of devices at the same time, scheduling thousands of USB packets every second, managing plug-and-play of the devices, and doing it all in the background without any interference to the normal stuff you're doing in the foreground. How could you possibly expect it to NOT be complicated? The code is heavily commented, so someone else could understand it if they took the time.
[Freedos-devel] Fwd: [Freedos-user] Install Problems
In case any of you couldn't read this. (Please respond to freedos-user). Aitor -- Forwarded message -- From: usul usul.the.mo...@gmail.com Date: 2009/3/18 Subject: [Freedos-user] Install Problems To: freedos-u...@lists.sourceforge.net I installed freedos correctlly or so I thought. When I boot from the hard drive and not the CD I get an F 99 99 99 (lots of nines) I can boot from the cd and see everything on the hard drive and run programs just fine. What did I do incorrectly? ~theMouse -- 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-u...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- 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-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Fwd: [Freedos-kernel] Error compiling ...
Sending over here too, as this list is more popular, and in case someone is not reading there and can contribute. Aitor -- Forwarded message -- From: Hans han...@ht-lab.com Date: 2009/2/15 Subject: Re: [Freedos-kernel] Error compiling ... To: freedos-ker...@lists.sourceforge.net The easy fix to this is use Watcom 1.2. Hans www.ht-lab.com - Original Message - From: George Petculescu To: freedos-ker...@lists.sourceforge.net Sent: Sunday, February 15, 2009 4:07 PM Subject: [Freedos-kernel] Error compiling ... Hello, I have a problem while compiling FreeDOS Kernel. I use latest version of Open Watcom and NASM 0.98. I recive the next error: Process BOOT +++ Process SYS wcc -Ic:\watcom\H -I..\hdr -DFORSYS -DWITHFAT32 -zq-zp1-os-s-we-e3-wx sys.c sys.c(1050): Warning! E1176: Parameter 2, pointer type mismatch sys.c(1050): Note! I2003: source conversion type is 'unsigned short *' sys.c(1050): Note! I2004: target conversion type is 'unsigned int *' sys.c(1050): Note! I2002: '_dos_allocmem' defined in: c:\watcom\H\dos.h(161) sys.c(1079): Warning! E1176: Parameter 2, pointer type mismatch sys.c(1079): Note! I2003: source conversion type is 'unsigned short *' sys.c(1079): Note! I2004: target conversion type is 'unsigned int *' sys.c(1079): Warning! E1176: Parameter 3, pointer type mismatch sys.c(1079): Note! I2003: source conversion type is 'unsigned short *' sys.c(1079): Note! I2004: target conversion type is 'unsigned int *' sys.c(1079): Note! I2002: '_dos_getftime' defined in: c:\watcom\H\dos.h(188) Error(E42): Last command making (sys.obj) returned a bad status Error(E02): Make execution terminated Compilation was aborted! What is the problem ? Should I wrong something in config.bat file ? Thanks, George. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Freedos-kernel mailing list freedos-ker...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Freedos-kernel mailing list freedos-ker...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: [Freedos-kernel] Error compiling ...
This looks like a real error to me !!! You can cast a short to an int, an the conversion in ok, but to cast a short* to an int* will bring in 2 extra bytes and an INVALID POINTER... Alain Aitor Santamaría escreveu: Sending over here too, as this list is more popular, and in case someone is not reading there and can contribute. Aitor -- Forwarded message -- From: Hans han...@ht-lab.com Date: 2009/2/15 Subject: Re: [Freedos-kernel] Error compiling ... To: freedos-ker...@lists.sourceforge.net The easy fix to this is use Watcom 1.2. Hans www.ht-lab.com - Original Message - From: George Petculescu To: freedos-ker...@lists.sourceforge.net Sent: Sunday, February 15, 2009 4:07 PM Subject: [Freedos-kernel] Error compiling ... Hello, I have a problem while compiling FreeDOS Kernel. I use latest version of Open Watcom and NASM 0.98. I recive the next error: Process BOOT +++ Process SYS wcc -Ic:\watcom\H -I..\hdr -DFORSYS -DWITHFAT32 -zq-zp1-os-s-we-e3-wx sys.c sys.c(1050): Warning! E1176: Parameter 2, pointer type mismatch sys.c(1050): Note! I2003: source conversion type is 'unsigned short *' sys.c(1050): Note! I2004: target conversion type is 'unsigned int *' sys.c(1050): Note! I2002: '_dos_allocmem' defined in: c:\watcom\H\dos.h(161) sys.c(1079): Warning! E1176: Parameter 2, pointer type mismatch sys.c(1079): Note! I2003: source conversion type is 'unsigned short *' sys.c(1079): Note! I2004: target conversion type is 'unsigned int *' sys.c(1079): Warning! E1176: Parameter 3, pointer type mismatch sys.c(1079): Note! I2003: source conversion type is 'unsigned short *' sys.c(1079): Note! I2004: target conversion type is 'unsigned int *' sys.c(1079): Note! I2002: '_dos_getftime' defined in: c:\watcom\H\dos.h(188) Error(E42): Last command making (sys.obj) returned a bad status Error(E02): Make execution terminated Compilation was aborted! What is the problem ? Should I wrong something in config.bat file ? Thanks, George. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Freedos-kernel mailing list freedos-ker...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Freedos-kernel mailing list freedos-ker...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: [Freedos-kernel] Error compiling ...
You can cast a short to an int, an the conversion in ok, but to cast a short* to an int* will bring in 2 extra bytes and an INVALID POINTER... no short * and int * are the exact same size in 16-bit compilers (try compiling a test program which prints sizeof(int), sizeof(short). For some reason openwatcom thinks it's an error. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: [Freedos-kernel] Error compiling ...
You can cast a short to an int, an the conversion in ok, but to cast a short* to an int* will bring in 2 extra bytes and an INVALID POINTER... no short * and int * are the exact same size in 16-bit compilers (try compiling a test program which prints sizeof(int), sizeof(short). For some reason openwatcom thinks it's an error. I don't know why unsigned short to unsigned int should be an error if they're the same size (probably so code doesn't get unportable due to this?), but the new OW 1.8 had changes regarding both _dos_allocmem and _dos_getftime. These either caused the warnings or they solved them (if they occured in 1.7) but I think the former: - The date and time arguments to _dos_getftime() and _dos_setftime() are now using 'unsigned int' type instead of 'unsigned short'. This change has been made to improve compatibility with other compilers. - The segment argument used with _dos_allocmem(), _dos_freemem() and _dos_setblock() is now unsigned int instead of unsigned short. This change was made for compatibility with other compilers. This is from http://openwatcom.org/index.php/C_Compilers_Release_Changes#List_of_changes_in_Open_Watcom_1.8 Regards, Christian -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: [Freedos-kernel] Error compiling ...
Christian Masloch escreveu: You can cast a short to an int, an the conversion in ok, but to cast a short* to an int* will bring in 2 extra bytes and an INVALID POINTER... no short * and int * are the exact same size in 16-bit compilers (try compiling a test program which prints sizeof(int), sizeof(short). For some reason openwatcom thinks it's an error. I don't know why unsigned short to unsigned int should be an error if they're the same size (probably so code doesn't get unportable due to this?), but the new OW 1.8 had changes regarding both _dos_allocmem and _dos_getftime. These either caused the warnings or they solved them (if they occured in 1.7) but I think the former: Ok, I allways use OW for 32 bit programs... for 16 bit it is ok, but at least not recomended. Using the link in the other message I found this, which plainly explains how this problem came around: * The date and time arguments to _dos_getftime() and _dos_setftime() are now using 'unsigned int' type instead of 'unsigned short'. This change has been made to improve compatibility with other compilers. * The segment argument used with _dos_allocmem(), _dos_freemem() and _dos_setblock() is now unsigned int instead of unsigned short. This change was made for compatibility with other compilers. A fix for this would requide conditionals based no the compiler version... really not nice at all :( Alain -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: [Freedos-user] Loading old DOS programs under FreeDOS
Hi Aitor, Seems interesting enough, in case noone saw this... Well there was a whole thread about the topic, and as far as I can tell, Word 5.5 works well enough in FreeDOS although I only tested in dosemu recently. If somebody can reproduce any problem or the absence of a problem, it would of course be interesting. Maybe something weird happens outside dosemu in some cases, maybe related to memory drivers or filesystem access? Eric PS: The rest of the mentioned thread was on -user ;-) PPS: You can download Word 5.5 from the MS homepage but some people say it is meant only for 5.0 owners, dunno. From: Steve Owens ess0w...@gmail.com Date: 2009/1/21 Subject: [Freedos-user] Loading old DOS programs under FreeDOS I had some problems loading my favorite DOS word processor (Word 5.5) under FreeDOS. This program is a download from the web... -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Fwd: [Freedos-user] Tiny Kernel incompatibility introduced in 2038?
-- Forwarded message -- From: Japheth m...@japheth.de Date: 2008/12/21 Subject: [Freedos-user] Tiny Kernel incompatibility introduced in 2038? To: FreeDOS User freedos-u...@lists.sourceforge.net Hello, in the latest FreeDOS kernels (from 03/2008 and 09/2007, AFAIU they are called 2038 and 2038pre) there might be a tiny incompatibility concerning the Ctrl-C handling. As a test case I use this version of the FTE editor: http://www.japheth.de/Download/FTE-HX.zip Once a text file has been loaded and one wants to press Ctrl-C to copy a line, the program terminates due to an exception. The kernel 2036 (date of binary is 05/2007) has no problems, and other DOS versions (MS-DOS) also work flawless. -- ___ Freedos-user mailing list freedos-u...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Fwd: [Freedos-user] Sad messages from ArachneDevelopment
FYI... -- Forwarded message -- From: Ulrich Hansen [EMAIL PROTECTED] Date: 2008/12/6 Subject: [Freedos-user] Sad messages from ArachneDevelopment To: [EMAIL PROTECTED] Is anybody reading this? http://tech.groups.yahoo.com/group/ArachneDevelopment/message/4093 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Fwd: [Freedos-user] Error in large files copied to floppies
Hello Marcos, Apparently the bug was not previously known, could you please fill-in a bugzilla entry so that it can be tracked? http://bugzilla.freedos.org/ Thanks! Aitor -- Forwarded message -- From: Marcos Favero Florence de Barros [EMAIL PROTECTED] Date: 2008/10/13 Subject: [Freedos-user] Error in large files copied to floppies To: FreeDOS List [EMAIL PROTECTED] Subject: Error in large files copied to floppies I have been experiencing some errors in files copied to floppies when file size approaches 1,457,664 bytes -- the total capacity of a common floppy. Today I tried to find the exact number of bytes that causes the problem, but apparently it is not constant. However, files above 1,452,300 got damaged in all my tests. This was observed in 3 different computers. The damage consists of parts of other files that get inserted near the end of the file. The problem surfaced because I use floppies to synchronize home and office computers. Some files need splitting, and the splitting program uses every available byte in the floppy. Subsequently I tested with common text files, i.e., files that did not originate from the splitting program. Different floppies were tested. They had been formatted with the command: format.exe A: /U /Q KERNEL.SYS is from 2007-12-08, and 4DOS.COM from 2004-08-25. Regards, Marcos Florence Brazil - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: freedos defrag methods (OT)
- Oorspronkelijk bericht - Van: Eric Auer [mailto:[EMAIL PROTECTED] Verzonden: dinsdag, maart 18, 2008 10:22 PM Aan: freedos-devel@lists.sourceforge.net Onderwerp: Re: [Freedos-devel] Fwd: freedos defrag methods (OT) Hi! For this it is very sad that FreeDOS does not use the LEAN file system (http://freedos-32.sourceforge.net/doc/lean.html) instead. That has back pointers for pretty much everything and would as a consequence be much faster. A lean ad ;-). LEAN was designed from the ground up for the FreeDOS project?! Imre Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: freedos defrag methods (OT)
Interesting... What information is tored in the FAT refered table it needs 32 bits? Alain Imre Leber escreveu: Here are the numbers for the data structures used by defrag, when calculated for FAT32. Cluster movable map: 32 MB (fat size * 1 bit) FAT refered map: 32MB (fat size * 1 bit) FAT refered table: 1024MB (fat size * 4 byte) Dir refered table (take 10 files): (# files * 6 bytes) 0,5 MB total: 1088,5 MB (and I though XMS only went to 64MB) In depth: Cluster movable map: indicates which clusters are movable. FAT refered map: indicates which clusters are refered to in the FAT FAT refered table: stores the back pointers for the FAT clusters DIR refered table: stores the back pointers for the directory refered clusters Imre - Oorspronkelijk bericht - Van: Eric Auer [mailto:[EMAIL PROTECTED] Verzonden: dinsdag, maart 18, 2008 10:22 PM Aan: freedos-devel@lists.sourceforge.net Onderwerp: Re: [Freedos-devel] Fwd: freedos defrag methods (OT) Hi! For this it is very sad that FreeDOS does not use the LEAN file system (http://freedos-32.sourceforge.net/doc/lean.html) instead. That has back pointers for pretty much everything and would as a consequence be much faster. A lean ad ;-). But you can just as well build data structures with the back pointers in RAM while defrag and similar tools are running. Takes roughly the same amount of RAM as the metadata (FAT, dir) takes on disk. As you often copy those to RAM for work like defragging to get fast access, you basically get some overhead for making the pointers plus you double the amount of RAM that defrag consumes ;-). Note that for example DOSFSCK takes several times the size of your FAT plus several times the size of all directory entries of RAM, too. Actually this would be interesting to know more about: Could some of you run DOSFSCK 2.11c with the -v option on large filesystems, with many files and/or many clusters, and report how much heap it tells you that it has used? It is displayed when DOSFSCK is done. Seems to be 5..10 times the FAT size for systems with few files here... Some bad case of FAT16 would be interesting (might use 1-5 MB maybe?) as well as, of course, typical FAT32 filesystems. You can find DOSFSCK version 2.11c on my page, as usual: www.coli.uni-saarland.de/~eric/stuff/soft/by-others/dosdosfsck-2.11c.zip (you should already have cwsdpmi anyway, otherwise see e.g. my page) Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: freedos defrag methods (OT)
Take the following cluster chain: 2 - 3 - 4 - EOF Then the FAT refered table contains: table[4] - 3 table[3] - 2 table[2] - 0 Well on FAT32 the labels are normaly 28bit, but that shouldn't realy matter. The FAT refered map is used to directly know wether to consult the FAT refered table or the DIR refered table. Imre - Oorspronkelijk bericht - Van: Alain M. [mailto:[EMAIL PROTECTED] Verzonden: woensdag, maart 19, 2008 07:49 PM Aan: freedos-devel@lists.sourceforge.net Onderwerp: Re: [Freedos-devel] Fwd: freedos defrag methods (OT) Interesting... What information is tored in the FAT refered table it needs 32 bits? Alain Imre Leber escreveu: Here are the numbers for the data structures used by defrag, when calculated for FAT32. Cluster movable map: 32 MB (fat size * 1 bit) FAT refered map: 32MB (fat size * 1 bit) FAT refered table: 1024MB (fat size * 4 byte) Dir refered table (take 10 files): (# files * 6 bytes) 0,5 MB total: 1088,5 MB (and I though XMS only went to 64MB) In depth: Cluster movable map: indicates which clusters are movable. FAT refered map: indicates which clusters are refered to in the FAT FAT refered table: stores the back pointers for the FAT clusters DIR refered table: stores the back pointers for the directory refered clusters Imre - Oorspronkelijk bericht - Van: Eric Auer [mailto:[EMAIL PROTECTED] Verzonden: dinsdag, maart 18, 2008 10:22 PM Aan: freedos-devel@lists.sourceforge.net Onderwerp: Re: [Freedos-devel] Fwd: freedos defrag methods (OT) Hi! For this it is very sad that FreeDOS does not use the LEAN file system (http://freedos-32.sourceforge.net/doc/lean.html) instead. That has back pointers for pretty much everything and would as a consequence be much faster. A lean ad ;-). But you can just as well build data structures with the back pointers in RAM while defrag and similar tools are running. Takes roughly the same amount of RAM as the metadata (FAT, dir) takes on disk. As you often copy those to RAM for work like defragging to get fast access, you basically get some overhead for making the pointers plus you double the amount of RAM that defrag consumes ;-). Note that for example DOSFSCK takes several times the size of your FAT plus several times the size of all directory entries of RAM, too. Actually this would be interesting to know more about: Could some of you run DOSFSCK 2.11c with the -v option on large filesystems, with many files and/or many clusters, and report how much heap it tells you that it has used? It is displayed when DOSFSCK is done. Seems to be 5..10 times the FAT size for systems with few files here... Some bad case of FAT16 would be interesting (might use 1-5 MB maybe?) as well as, of course, typical FAT32 filesystems. You can find DOSFSCK version 2.11c on my page, as usual: www.coli.uni-saarland.de/~eric/stuff/soft/by-others/dosdosfsck-2.11c.zip (you should already have cwsdpmi anyway, otherwise see e.g. my page) Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: freedos defrag methods (OT)
Hi Imre, nice explanation, thanks :-). Here are the numbers for the data structures used by defrag, when calculated for FAT32. You mean for a worst case FAT32 filesystem with 2^28 (256M) clusters where the FAT on disk is also 1 GB per copy... Cluster movable map: 32 MB (fat size * 1 bit) FAT refered map: 32MB (fat size * 1 bit) FAT refered table: 1024MB (fat size * 4 byte) Dir refered table (take 10 files): (# files * 6 bytes) 0,5 MB total: 1088,5 MB (and I though XMS only went to 64MB) So its dominated by one FAT32 copy plus small stuff :-) Actually XMS2 goes to 64 MB, but on a 286, you can only have 16 MB. When you use XMS3, you get up to 4 GB, but the interface of XMS3 uses 32bit registers so if your software uses XMS3, it no longer runs on 286 or older ;-). Cluster movable map: indicates which clusters are movable. Okay :-). Are many clusters non movable? FAT refered map: indicates which clusters are refered to in the FAT What does that mean? FAT refered table: stores the back pointers for the FAT clusters Interesting. You could probably make a sparse variant of this by making the default assumption previous cluster or none points to this cluster and only storing the exceptions to that rule in a hashtable. Whether it is previous or rather none is easily found out by looking at the FAT. DIR refered table: stores the back pointers for the directory refered clusters Useful and quite small :-) Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Fwd: freedos defrag methods
Here is the explanation: The old methods start by going through the disk from start to finish. For every cluster it determines which file it has to put there. The file that is in the way is moved to a different location and the file that should be there is put in that location. This is very slow. Moreover since much more data is copied, it tends to be sensitive to disk corruption (resetting the computer is a very bad idea). The new methods, go through the directory tree once, determining which files are fragmented. For every fragmented file it looks for a location where it can put it continously. Then it puts the file there. Result: very fast and far less copying. Moreover data that does not need to be copied stays where it is. Drawback: on some systems where the disk may be too full, it might not be able to defragment all files (hence: quick try). Imre - Oorspronkelijk bericht - Van: Eric Auer [mailto:[EMAIL PROTECTED] Verzonden: maandag, maart 17, 2008 01:56 PM Aan: 'Imre Leber' Onderwerp: Re: freedos defrag methods Hi! Well the old methods from MSDOS are still supported for historical reasons. I think for smaller partitions (FAT16), they are still useful... But anybody serious about defragmentation should use the new quick try methods. Can you give some more explanation about the pros and cons of the quick try methods? That is the only sane and safe way to do it. No method should be unsafe - which have unsafe implementations? Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: freedos defrag methods
I'm tried to defragment my 10Gb hdd fat32 .I choose quick try. terminate the working the disk map appears not fragmented. I quit and exit, then restarting defrag: the map it's the same as before quick try. Why? Imre Leber wrote: Here is the explanation: The old methods start by going through the disk from start to finish. For every cluster it determines which file it has to put there. The file that is in the way is moved to a different location and the file that should be there is put in that location. This is very slow. Moreover since much more data is copied, it tends to be sensitive to disk corruption (resetting the computer is a very bad idea). The new methods, go through the directory tree once, determining which files are fragmented. For every fragmented file it looks for a location where it can put it continously. Then it puts the file there. Result: very fast and far less copying. Moreover data that does not need to be copied stays where it is. Drawback: on some systems where the disk may be too full, it might not be able to defragment all files (hence: quick try). Imre - Oorspronkelijk bericht - Van: Eric Auer [mailto:[EMAIL PROTECTED] Verzonden: maandag, maart 17, 2008 01:56 PM Aan: 'Imre Leber' Onderwerp: Re: freedos defrag methods Hi! Well the old methods from MSDOS are still supported for historical reasons. I think for smaller partitions (FAT16), they are still useful... But anybody serious about defragmentation should use the new quick try methods. Can you give some more explanation about the pros and cons of the quick try methods? That is the only sane and safe way to do it. No method should be unsafe - which have unsafe implementations? Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- View this message in context: http://www.nabble.com/Fwd%3A--freedos-defrag-methods-tp16119594p16120340.html Sent from the FreeDOS - Dev mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: freedos defrag methods
Hi! I tried to defragment my 10Gb fat32 hdd. I choose quick try. terminates: the working the disk map appears not fragmented. I quit and exit, then restarting defrag: the map is the same as before quick try. Because quick try only takes care that each file consists of only ONE area on the disk. It does not take care that there are no unused areas BETWEEN the files... I guess you could do a second run after the quick try in some mode like move files to the beginning of the disk. Worst case would be that this mode has to copy every used data cluster once. This is slow but not as slow as having to move files out of the way. So combining defragment files, quick try style with a 2nd step move files and dirs to the beginning of the disk after that should give you a completely defragmented and compact disk (nice for filesystem resize and nice for speed) in most cases. In SOME cases, when there is not enough consecutive free space for the quick try file defrag, only the very SLOW (and more sensitive) full defragmentation in old style could help you. I hope I explained that correctly :-) Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: freedos defrag methods
- Oorspronkelijk bericht - Van: Eric Auer [mailto:[EMAIL PROTECTED] Verzonden: dinsdag, maart 18, 2008 01:54 PM Aan: freedos-devel@lists.sourceforge.net Onderwerp: Re: [Freedos-devel] Fwd: freedos defrag methods Hi! I tried to defragment my 10Gb fat32 hdd. I choose quick try. terminates: the working the disk map appears not fragmented. I quit and exit, then restarting defrag: the map is the same as before quick try. Because quick try only takes care that each file consists of only ONE area on the disk. It does not take care that there are no unused areas BETWEEN the files... I guess you could do a second run after the quick try in some mode like move files to the beginning of the disk. Worst case would be that this mode has to copy every used data cluster once. This is slow but not as slow as having to move files out of the way. So combining defragment files, quick try style with a 2nd step move files and dirs to the beginning of the disk after that should give you a completely defragmented and compact disk (nice for filesystem resize and nice for speed) in most cases. In SOME cases, when there is not enough consecutive free space for the quick try file defrag, only the very SLOW (and more sensitive) full defragmentation in old style could help you. I hope I explained that correctly :-) Yes, except that move the files to the front of the disk is still way too slow. Sorry but that is what is has to be. Moving any amount of data on FAT32 will never work, unless you have a week or so to let the program run. That's why windows defrag doesn't do this, and that is why we don't do it. Just to give an indication of how infinitely slow it is try crunching a FAT16 volume of some 2GB and then multiply that by a factor of 5 or so. This goes up very fast if the volume is larger then 2GB. Imre Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: freedos defrag methods (OT)
For this it is very sad that FreeDOS does not use the LEAN file system (http://freedos-32.sourceforge.net/doc/lean.html) instead. That has back pointers for pretty much everything and would as a consequence be much faster. Voting for a file system change ;-D Imre - Oorspronkelijk bericht - Van: Imre Leber [mailto:[EMAIL PROTECTED] Verzonden: dinsdag, maart 18, 2008 07:10 PM Aan: freedos-devel@lists.sourceforge.net Onderwerp: Re: [Freedos-devel] Fwd: freedos defrag methods - Oorspronkelijk bericht - Van: Eric Auer [mailto:[EMAIL PROTECTED] Verzonden: dinsdag, maart 18, 2008 01:54 PM Aan: freedos-devel@lists.sourceforge.net Onderwerp: Re: [Freedos-devel] Fwd: freedos defrag methods Hi! I tried to defragment my 10Gb fat32 hdd. I choose quick try. terminates: the working the disk map appears not fragmented. I quit and exit, then restarting defrag: the map is the same as before quick try. Because quick try only takes care that each file consists of only ONE area on the disk. It does not take care that there are no unused areas BETWEEN the files... I guess you could do a second run after the quick try in some mode like move files to the beginning of the disk. Worst case would be that this mode has to copy every used data cluster once. This is slow but not as slow as having to move files out of the way. So combining defragment files, quick try style with a 2nd step move files and dirs to the beginning of the disk after that should give you a completely defragmented and compact disk (nice for filesystem resize and nice for speed) in most cases. In SOME cases, when there is not enough consecutive free space for the quick try file defrag, only the very SLOW (and more sensitive) full defragmentation in old style could help you. I hope I explained that correctly :-) Yes, except that move the files to the front of the disk is still way too slow. Sorry but that is what is has to be. Moving any amount of data on FAT32 will never work, unless you have a week or so to let the program run. That's why windows defrag doesn't do this, and that is why we don't do it. Just to give an indication of how infinitely slow it is try crunching a FAT16 volume of some 2GB and then multiply that by a factor of 5 or so. This goes up very fast if the volume is larger then 2GB. Imre Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: freedos defrag methods
Maybe with adding compression it could make a replacement for doublespace? (running it through the network redirector obviously) Imre - Oorspronkelijk bericht - Van: Imre Leber [mailto:[EMAIL PROTECTED] Verzonden: dinsdag, maart 18, 2008 07:10 PM Aan: freedos-devel@lists.sourceforge.net Onderwerp: Re: [Freedos-devel] Fwd: freedos defrag methods - Oorspronkelijk bericht - Van: Eric Auer [mailto:[EMAIL PROTECTED] Verzonden: dinsdag, maart 18, 2008 01:54 PM Aan: freedos-devel@lists.sourceforge.net Onderwerp: Re: [Freedos-devel] Fwd: freedos defrag methods Hi! I tried to defragment my 10Gb fat32 hdd. I choose quick try. terminates: the working the disk map appears not fragmented. I quit and exit, then restarting defrag: the map is the same as before quick try. Because quick try only takes care that each file consists of only ONE area on the disk. It does not take care that there are no unused areas BETWEEN the files... I guess you could do a second run after the quick try in some mode like move files to the beginning of the disk. Worst case would be that this mode has to copy every used data cluster once. This is slow but not as slow as having to move files out of the way. So combining defragment files, quick try style with a 2nd step move files and dirs to the beginning of the disk after that should give you a completely defragmented and compact disk (nice for filesystem resize and nice for speed) in most cases. In SOME cases, when there is not enough consecutive free space for the quick try file defrag, only the very SLOW (and more sensitive) full defragmentation in old style could help you. I hope I explained that correctly :-) Yes, except that move the files to the front of the disk is still way too slow. Sorry but that is what is has to be. Moving any amount of data on FAT32 will never work, unless you have a week or so to let the program run. That's why windows defrag doesn't do this, and that is why we don't do it. Just to give an indication of how infinitely slow it is try crunching a FAT16 volume of some 2GB and then multiply that by a factor of 5 or so. This goes up very fast if the volume is larger then 2GB. Imre Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: freedos defrag methods (OT)
Hi! For this it is very sad that FreeDOS does not use the LEAN file system (http://freedos-32.sourceforge.net/doc/lean.html) instead. That has back pointers for pretty much everything and would as a consequence be much faster. A lean ad ;-). But you can just as well build data structures with the back pointers in RAM while defrag and similar tools are running. Takes roughly the same amount of RAM as the metadata (FAT, dir) takes on disk. As you often copy those to RAM for work like defragging to get fast access, you basically get some overhead for making the pointers plus you double the amount of RAM that defrag consumes ;-). Note that for example DOSFSCK takes several times the size of your FAT plus several times the size of all directory entries of RAM, too. Actually this would be interesting to know more about: Could some of you run DOSFSCK 2.11c with the -v option on large filesystems, with many files and/or many clusters, and report how much heap it tells you that it has used? It is displayed when DOSFSCK is done. Seems to be 5..10 times the FAT size for systems with few files here... Some bad case of FAT16 would be interesting (might use 1-5 MB maybe?) as well as, of course, typical FAT32 filesystems. You can find DOSFSCK version 2.11c on my page, as usual: www.coli.uni-saarland.de/~eric/stuff/soft/by-others/dosdosfsck-2.11c.zip (you should already have cwsdpmi anyway, otherwise see e.g. my page) Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] [Fwd: freedos]
I got this today and decided to forward it -- Gregory Pietsch ---BeginMessage--- i have a few questions. i asume that freedos runs ms-dos programs, is that correct? I have fdbootcd.iso, if a burn a cd and want to install it on the pc it won't boot, can you help me (or somebody else), i use nero for bruning. is it possible to use a 8 gb hd with freedos (no other system on the pc) maarten ---End Message---
[Freedos-devel] [Fwd: freedos and networking]
I got this from Pierre-Richard Potgeiter. -- Gregory Pietsch ---BeginMessage--- Hi How are you? I have hit a brick wall with trying to get Lantastic to work on Freedos, We run a Point of sale on dos and now we have to switch to freedos, It's a very nice system, We use lantastic to communicate between the POS's, I can get the POS to run hundred percent on freedos but when i try to load lantastic it loads aslong as you have the correct drivers but when it reboots it complains about not loading in High Mem, we managed to work around that but now it just refuses to work, Do you know if lantastic will work on Freedos or is there another networking protocol that we can use to communicate to windows from a FREEDOS machine. Thanx very much I really appreciate your help Pierre Pierre-Richard PotgieterSoftware SupportHRK AFRICA (PTY) LTDTel: 31 2668861/2Fax : 31-2660102[EMAIL PROTECTED] or [EMAIL PROTECTED] Glacier Bkgrd.jpg---End Message---
[Freedos-devel] [Fwd: freedos and networking]
Hi Pierre-Richard, There is one very good MS-Client for windows that is 100% free from a most unexpected source: MICRO$OFT. It was released for Win311 and states very clearly that it is free. If you do not find it I can Try to find where mine is I tested it more than a year ago and it worked great! I tested with Windows 98SE and Samba too :) At the time it had only one bug, wit Clipper command APPEND BLANK but maybe it is fixed now (the problem was with a double lock on a file). If not I am sure someone could help (I personaly spent many hours on it, and handed it over to Tom...) Alain PS, be wellcome to join the list ;-) -- Hi How are you? I have hit a brick wall with trying to get Lantastic to work on Freedos, We run a Point of sale on dos and now we have to switch to freedos, It's a very nice system, We use lantastic to communicate between the POS's, I can get the POS to run hundred percent on freedos but when i try to load lantastic it loads aslong as you have the correct drivers but when it reboots it complains about not loading in High Mem, we managed to work around that but now it just refuses to work, Do you know if lantastic will work on Freedos or is there another networking protocol that we can use to communicate to windows from a FREEDOS machine. Thanx very much I really appreciate your help Pierre Pierre-Richard Potgieter Software Support HRK AFRICA (PTY) LTD Tel: 31 2668861/2 Fax : 31-2660102 [EMAIL PROTECTED] or [EMAIL PROTECTED] --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] [Fwd: FreeDOS]
Hello. My company processes (removes microsoft information) and resells 1,000 - 1,500 major-label PCs a month. The OEM would like us to add FreeDOS licenses to these PCs. just the license? is this the MS all computers must be delivered with an OS requirement? what's the current wiping process? 'Fdisk - remove all partitions - create a single primary partition' ? anyways, easiest to do would be to obtain the kernel 2035 package [ http://heanet.dl.sourceforge.net/sourceforge/freedos/ke2035_32.zip ] and the license under which the main part of the FreeDOS software has been released: the GPL. then the license is on the computer, but end-user still needs to read it. in case of just a license and not a full freedos, I'd suggest the following: kernel.sys command.com more.com license.txt autoexec.bat (with following contents): @echo off echo Full freeDOS can be obtained from: http://www.freedos.org/freedos/files/ echo Press a key to read the license which came with the operating system of this computer. rem remove next line if you don't want to read the license. type license.txt | more The requirement is that we put some sort of documentation into each box - either a FreeDOS license or a document that points the end-user to FreeDOS. What do you recommend. Bernd --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] [Fwd: FreeDOS]
---BeginMessage--- Title: Message Hello. My companyprocesses (removes microsoft information)and resells 1,000 - 1,500 major-label PCs a month.The OEMwould like us to add FreeDOS licenses to these PCs. The requirement is that weput some sort of documentation into each box - either a FreeDOS license ora document that points the end-user to FreeDOS. What do you recommend. Regards, Grant * Grant Guilbeault CEO FastAsset, Inc. 170 West Road Portsmouth, NH 03801 603-559-9900 800-794-6065 603-559-9901 fax [EMAIL PROTECTED] ---End Message---
