Re: [Freedos-devel] working 720k format tool anybody? mirror speed okay?
So what is this all about? Maybe a general compatibility problem? Do I have to use DD disks to be able to format to DD? If LBAcache would be to blame: I unloaded it, no difference. That is the good question: I have never been able to format a 720k disk without closing the other identifying hole :) Alain --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Please try new HIMEM64
Hi Michael, first of all, thanks, 1. There are five different A20 tests described using the nomenclature: fast, BIOS, KBC, Vectra, and Always On, tried in that order. Whichever test succeeds, if any, will give feedback that it was selected. Perhaps that should only happen with the /VERBOSE option? It should display some discreet message, just informative. Only aditional debuging info should be in the /VERBOSE mode ;-) 2. INT 15h, function 87h, was hooked to save and restore A20 status for any BIOS or other INT 15h hooking program which neglects to perform this rather key function. The new code represents the input of five or six FreeDOS developers, code from at least three, and, indirectly from all the public A20 code out there which was used, further input from a cast of thousands. Uau !! - Maybe a change back to the original A20 check code, some disagreement there. For some misterious reason, FreeDOS memeory manager is a very hot subject. IMHO you should just use good common sense (as you have been doing) ;-) Alain --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Executable compression
I just want to add something to the GPL issue: There is nothing to prevent a GPL'd program to be distributed "combined" with proprietary code. Only the other way around is restricted. So if someone is willing to pay for aPack so that we can use his personal distribution, I will thank him very much ;-) Alain So, we are (OK, I am) in the trap of our own license! The GPL, instead of giving us freedom, takes it away from *us*, the *developers*! Isn't that absurd?! :-( --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [spam score 5/10 -pobox] Re: [Freedos-devel] Re: GPL and other licenses
Luchezar Georgiev escreveu: Oh, if you or I could do that! Good dream, but too difficult to do :( So we're STUCK with the GPL! We cannot forget that if it were *not* GPL it would not have had so many people helping ;-) Alain --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re:Eric's idea to put "PG binaries online"
HI, I have a BIG question: What is PG? I just searched the site, followed every link and could not find any explanation, it only says how it can solve "many" PC problems, not even specifying which... If so many people in FreeDOS are interested, I would like to know about ;-) Alain --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Don't you think its better to use Msdos file names?
Steve Nickolas escreveu: At Fri, 20 Feb 2004 3:19pm -0500, togermano.com wrote: Don't you think its better to use Msdos file names? So like a program can edit it. And its easyer for people that know msdos file names instead of like fddos for a directory etc.. Opinions vary but I do agree. -uso. I also agree. This was discussed some time ago, but we could open the chapter again because FreeDOS is getting really mature now I would prefer a C:\DOS directory with all exacutables inside. Users will feel more confortable with it ;-) Alain --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: UDMA as base?
Thanks, Aitor, Bernd, Erwin, Jim, Johnson, Steve, and all others who wrote good words about UDMA, and of course, UDMA author Jack R. Ellis for his great, innovative and pioneering work on UDMA! Lucho Well now let's consider which UDMA or UUDMA to use? I allways understood that the most up-to-date and more frequently updated is UUDMA? Am I correct or not? Both ways, the version to include in 'base' should be selected by LUCHO... Alain --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Don't you think its better to use Msdos file names?
Jim Hall escreveu: DOS- all exe/com/sys files Definetly yes DOS\HELP - all help files but the help command should be in the DOS directory Alain --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: file to diskette
Hi, This brings a very important question: If I create an image with FreeDOS's disckcopy, can I write it back with rawrite? Are they compatible? Alain Kenneth J. Davis escreveu: Hi Arkady! To write a diskimage to disk, simply use FreeDOS DISKCOPY. For Windows, use: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/tools/imgtool.zip RAWRITE is deprecated. Get diskcopy from dkcp092x.zip at: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/diskcopy/ The ZIP in which you download ODIN already contains a disk image writing tool for your convenicene, I think it was DISKCOPY. You are right, this is not well explained on the beta9rc4 download site, which tools to use and where to get them. Eric. See also http://www.fdos.org/ripcord/rawrite/readme.txt for a fairly large list of rawrite like programs for various OSes. Jeremy --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: "Undocumented DOS" by Andrew Schulmann
Luchezar Georgiev escreveu: [...]if anyone has this (or Pat's) book and wants to sell it to me, you're welcome ;-) I would by one too. anywhere even with a credit card. I have already searched but could not find it :( Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: "Undocumented DOS" by Andrew Schulmann
Heh, how bad do you want it? Ventura Pacific lists one for $165 and Abe Books has it for $175 via online purchase -- plus whatever shipping to get it overseas, of course. Totally outrageous, but I guess they know it's hard to get. Makes me wonder what I could get for my old MS-DOS Encyclopedia and the copy of Extending DOS. Please confirm if this is the right book: Undocumented DOS: A Programmer's Guide to Reserved MS-DOS Functions & Data Structures By Andrew Schulman, Raymond J. Michels, Jim Kyle, Tim Paterson, David Maxey, Ralf Brown I found it at http://www.fetchbook.co.uk/compare.do?search=0201570645 for £22.01 Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Version 1.0
Hi all, There has been a message today (I just lost it :( ) about FreeDOS 1.0 and I want to give my opinion: Only one program is missing and that is a Scan-Disk (written as 2 words) utility for Fat32. For what I kow, DOSFSCK is working and need only a small fixes in the read sector. IMHO a working version od DOSFSCK should be included in version 1.0 to have a full set of tools. I don't believ that we will see a working and debugged version of either chkdsk or scandisk any time soon ... Now we have a good FORMAT, and even a EMM386 (will be working soon) :) Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 with VCPI for testing
Ho Michael, first of all, many thanks :) EMM386 will only allocate VCPI memory from the EMS memory pool. Making it automatically use the XMS memory pool would require backdoor interaction > with HIMEM[64] and generally make things quite a bit more complex. Of course, a DOS extender/extended program can still use XMS in addition to > VCPI and many of them do. I can see aproblem here (or I can have missunderstood): IMHO what will be used a lot is UMB+VCPI without EMS. The reason for this configuration is whe 1) UMBPCI does not work (new hw), 2) no need for EMS (few programs use it) 3) free as much as possible Low-Memory for comon programs (EMS takes 64k of UMB)(very often needed). Will this configuration work?? Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FREEDOS
Hi Amy, I am not the official mantainer, but I can assure you that FreeDOS works well with both Fat16 anf Fat32. As far as I know there is no knwn bug, and I am using it on same machines without problem for quite a while :) Alain PS: as you sent your address I am bcc'ing this to you. Amy Moffett escreveu: TO WHOM IT MAY CONCERN; I HAVE A QUESTION REGARDING FREEDOS AND WETHER OR NOT FREEDOS WILL RUN ON FAT 16 HARDDRIVE PARTITION TO 2 GIG OR LARGER WITHOUT USING A 'SHARE' PROGRAM OR ANYTHING RELATED. PLEASE CALL ME @ 716-822-8284 M-F 8AM TO 4:30PM OR E-MAIL ME AT [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> my name is amy moffett and i work for colgate industries! thank you! --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Version 1.0
Only one program is missing and that is a Scan-Disk (written as 2 words) Afraid of the M1CR0$0FT police? ;-) Let's swap the words then and call it DISKSCAN! No, I am afraid of starting another message war. There are some people here working in a "scandisk" utility for Fat32. For what I kow, DOSFSCK is working and need only a small fixes in the read sector. If there is a volunteer for this Herculean feat, I'd suggest integrating DOSFSCK into DISKSCAN. for what I know, it is already working, the problem is just that the maintainter doesn't know how and does not have time to learn how to write a read/write absolute sector (it has to run on djgpp). Many people here could help on just this item ;-) IMHO a working version od DOSFSCK should be included in version 1.0 to have a full set of tools. Agreed. :) :) Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [spam score 3/10 -pobox] Re: [Freedos-devel] EMM386 with VCPI for testing
Hi Michael, EMM386 will only allocate VCPI memory from the EMS memory pool. Making it automatically use the XMS memory pool would require backdoor interaction with HIMEM[64] and generally make things quite a bit more complex. Of course, a DOS extender/extended program can still use XMS in addition to VCPI and many of them do. I can see aproblem here (or I can have missunderstood): IMHO what will be used a lot is UMB+VCPI without EMS. The reason for this configuration is whe 1) UMBPCI does not work (new hw), 2) no need for EMS (few programs use it) 3) free as much as possible Low-Memory for comon programs (EMS takes 64k of UMB)(very often needed). Will this configuration work?? Depends. Some extenders have absolutely no problem allocating from XMS if no VCPI memory available. For what I learned here, if the machine is not in real mode, which is needed to get UMB, then VCPI is needed. am I wrong? Unfortunately, DOS/4GW, now crowned That Annoying Extender Which Grossly Misbehaves, doesn't like current EMM386 NOEMS. I'm still trying to sort that out and am not sure whether it's due to no memory in VCPI pool, missing EMS page frame, or something else. NOEMS is pretty badly broken in the EMM386 version out there anyway, but I've fixed it up some for next patch release. Now NOEMS allocates up to 192K for UMB's and VCPI internal table use, which typically leaves at least 32K for a VCPI pool, more if you have fewer UMB's. What is himem+emm386 footprint in memor(low+umb)? The DOS/4GW problem does need to be addressed since it's most popular extender out there and a lot of legacy applications use it. Agreed ;-) I'm thinking maybe if the residual EMS left-over after UMB allocation is too low, I'll have EMM386 by default grab a hunk of XMS memory at startup to keep for as VCPI pool. Biggest hurdle is that this behavior is not the most friendly use of memory. And if I do that, I'll need to slightly modify HIMEM again to increase default handles, since it's already pretty low without EMM386 grabbing memory. What would you think about an EMM386 that decided to steal some of your XMS memory at startup, just in case a VCPI-using program wanted it later on? I mean, the memory might never be needed if nothing ran which used VCPI, it would just be gone. Proper settings would need some type of command line parameter control, but we really need is a basic default for the general Joe and Joyce User who simply sticks NOEMS in there and still expects their DOS-extended to run with a DOS extender or related protected mode application than can't fallback to XMS allocation. I think that we should consider a bit who is Averege-Joe and what machine he may get. 1) if he has no knwledge of dos at all (just a mouse-clicker) and is just testing, he has a powerfull machine and will not care as long as everything runs. For him a good installer is the most important thing. 2) for an old-time DOS user that is really using FreeDOS to run old programs (like Clipper systems) he has at least 4Mb of memory. In this case it FreeDOS should a) run just out-of-the-box and b) could be optimised later if this is really needed 2) for small enbedded systems, anything will be highly optimised and this Joe has the knwledge to do it. So here default are not a problem. SO: default values should have any value that make the system work smoothly. It just ocurred to me that these values could be dependant on the total amount of memory found in the machine. MS-DOS has this in many places. This way if there is at least 4Mb, a little more in various tables is wellcome. Alain PS What program are usint to write you messages? my Thunderbird is behaving strangely in the answer screen and I have to break lines manually. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [spam score 3/10 -pobox] Re: [Freedos-devel] EMM386 with VCPI for testing
Michael Devore escreveu: At 07:34 PM 3/10/2004 -0300, Alain wrote: EMM386 will only allocate VCPI memory from the EMS memory pool. Making it automatically use the XMS memory pool would require backdoor interaction with HIMEM[64] and generally make things quite a bit more complex. Of course, a DOS extender/extended program can still use XMS in addition to VCPI and many of them do. I can see aproblem here (or I can have missunderstood): IMHO what will be used a lot is UMB+VCPI without EMS. The reason for this configuration is whe 1) UMBPCI does not work (new hw), 2) no need for EMS (few programs use it) 3) free as much as possible Low-Memory for comon programs (EMS takes 64k of UMB)(very often needed). Will this configuration work?? Depends. Some extenders have absolutely no problem allocating from XMS if no VCPI memory available. For what I learned here, if the machine is not in real mode, which is needed to get UMB, then VCPI is needed. am I wrong? No, it's not necessary. UMB's are mapped at startup by the EMM. VCPI is simply an interface (the 'I' part of the acronym) with EMM386 to make it, among other things, do what you want from V86, aka virtual 8086, mode. V86 is what DOS runs at under EMM386 rather than real mode. The EM monitor itself substantially runs in protected mode. Some cpu instructions _cannot_ be used in V86 mode in i586 machines. So if the machine _is_ in V86 someone has to control it, ok? that one is VCPI, ok? So if I need UMB without umbpci, I need to put the machine in V86 mode. What you are saying is that _some_ dos extenders (but not dos4gw) can do that even without VCPI, ok? Sorry, but it looks like I missunderstood something somewhere, this is why I am re-phrasing most of what you say so that I can see where is my erros ;-) What is himem+emm386 footprint in memor(low+umb)? Don't know. HIMEM conventional memory footprint is low, around 3K(?) someone said a while back. EMM386 is growing and definitely higher than that, although most internal tables and structures are in high memory outside of pure DOS. I did misstate how the NOEMS allocation for UMB's works. Under NOEMS EMM386 allocates enough for the current UMB's, plus 32K for VCPI, meaning lower UMB's allocations won't increase the minimum VCPI pool size. Right now, EMM386 shuts off VCPI if there isn't a minimum 32K for VCPI after UMB allocation, but I'm probably going to change that since some programs will work with a zero-sized VCPI pool. I think. So EMM386 has a small code in memory, _plus_ 32k for the VCPI pool. The diference seems to be that this 32k are hidden somewhere in MS-EMM386, ok? Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Message problem EudoraPro/Thunderbird on this list
Michael Devore escreveu: PS What program are usint to write you messages? my Thunderbird is behaving strangely in the answer screen and I have to break lines manually. I'm using Eudora Pro, plain text, to stop Eric from griping in his enthusiastic role as HTML policeman. Hard line breaks in regular text are generally frowned upon in messaging per ancient Usenet rules et al, so I don't use them. A few million people on the Internet like to gripe about hard line breaks. And then there's top-posting, which I still sometimes do and refuse to stop. And cap rules. And style rules. Matter of fact, you'd almost think most people out there in the world like to gripe. Not me, of course, although naturally I offer many unsolicited suggestions and opinions purely for the benefit of others. Is anyone else using Eudora Pro? Please send me a message with a paragraph 3 to 4 lines. When I am answering the message, every paragraph opens in one single very long line. All other messages seem to work normaly. Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: Version 1.0
Hi Eric, Only one program is missing and that is a Scan-Disk (written as 2 words) utility for Fat32. For what I kow, DOSFSCK is working and need only a small fixes in the read sector. I strongly disagree. :( see beloww Our SCANDISK for FAT1x is completely defunct, so we have no SCANDISK in the meaning of "nice looking user interface to the CHKDSK and DOSFSCK engines" at all. I agree :) My DOSFSCK-2.8-FAT32 currently works okay, but a working 2.10 port would be much better. IIRC ther is some bug in this version that is _not_ related to the dos port and it behaves strangely with some fat erros. Again IIRC this is ok in next version... I hope Imre can find the time to add working lowlevel disk access drivers to 2.10 (does not work at all for me for FAT16 in FreeDOS). It would not be THAT hard. That is what I said. Have a look at my 2.8-FAT32 (can only read, only compiles okay in Turbo C, not in Borland C, as dosfsck is a Linux program, it will probably work well only under DJGPP. For the Fat32 version this is ok as it need lots of memory anyway. see recent absread discussion) and Imres 2.10, maybe YOU can help us and provide a working "can read and write all FAT types" 2.10 ... I wish I could help. FWIK, you (Eric) have some knowledge about it and Andreas has too but he will be too busy in the next few months. I will have some free time next month, but I don't even know where to look at to start :( I was just hoping that your previous work with lbacache would make it easyer for you ;-) What else is missing? is is my particular and very BIASED opinion: RAMDISK problems are a bit vague... Maybe even kernel related. XMSDSK is 100% functional and free _can_ be used FDISK - The newest 1.21 (?) version seems to be better than 1.20, but I think there are still important bugs on some systems. Updates planned? ?? are these rally bad or are they related to uncommon file systems? FORMAT - With all feedback from "Fritz" and Johnson I still could not figure out why running FreeDOS FORMAT under Windows creates broken FAT32. All boot sector fields look okay for me but still the root directory is accessed at the wrong place by Windows. But I am confident that something will come around soon ;-) MODE and KEY ... are underway thanks to Aitor FreeCOM should at least fix the following bugs / problems: Overwriting file by nonexisting file zaps file. I believe this is fixed Context memory has a memory leak. ?? looks bad Renaming dir with trailing \ makes it disappear. ?? looks bad Most other problems I (personaly) don't see as show stoppers Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re3: Version 1.0
Hi Eric, RAMDISK problems are a bit vague... Maybe even kernel related. XMSDSK is 100% functional and free _can_ be used I do not think so. While XMSDSK generally works nice, it has - as any other ramdisk that I have tested so far - the strange problem that LCD (interactive change dir) immediately exits to the prompt when touching it, and even worse, that DPMI16BI compiled programs like the Jazz Jackrabbit game crash if any ramdisk is present at all (do not even have to have a reason to touch any file on that ramdisk). Maybe you could try several ramdisks, several XMS drivers and several kernel versions and try to find out if any combination works okay for you. Ok, I didn't know about those. I use it in Win98se as the better of all I tested, but only with certain parameters. I have used it with DPMI16 programs without problems, but I don't know if it was "BI". About FDISK 1.21: I only use Linux fdisk, so I do not know. I don't trust those a lot too. The command line version is probably safe, but so difficult to use that it is too prone to human error (myself), the graphic versions are not very reliable. I use Partition Magic as the best overall: it is really easy to make sure of what you are doing and never any friend reported a problem even with the crazy things that it can do. Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 with VCPI for testing
Michael Devore escreveu: [...] Thanks for all the explanations, they were very intereting and instructing. But something is still missing, I will keep on reading until I find the missing link ;-) What is himem+emm386 footprint in memor(low+umb)? Don't know. HIMEM conventional memory footprint is low, around 3K(?) someone said a while back. EMM386 is growing and definitely higher than that, although most internal tables and structures are in high memory outside of pure DOS. I did misstate how the NOEMS allocation for UMB's works. Under NOEMS EMM386 allocates enough for the current UMB's, plus 32K for VCPI, meaning lower UMB's allocations won't increase the minimum VCPI pool size. Right now, EMM386 shuts off VCPI if there isn't a minimum 32K for VCPI after UMB allocation, but I'm probably going to change that since some programs will work with a zero-sized VCPI pool. I think. So EMM386 has a small code in memory, _plus_ 32k for the VCPI pool. The diference seems to be that this 32k are hidden somewhere in MS-EMM386, ok? No, the 32K is from extended memory, just like the standard EMS memory. It gets swiped from the EMS pool, as needed. VCPI and EMS memory are a shared pool. The 32K doesn't affect the DOS conventional memory footprint. Very nice... Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: Version 1.0
Hi Aitor, PS: Sorry if I was a little bit though, I am still a bit shocked. New list promised this week (except maybe polishing the post-1.0 list, but will do my best too) I could be somewhat at fault here. I started a thead about version 1.0 unreguarding your comming list. the fact is that IMHO that list is too big, and not too well priorised. As an example there are many commands there that don't even exist in MS-DOS, like undelete. When I started that thread, I was hoping that I could bring someone to help dosfsck which in my opinion is the most needed feature that is not advancing... cheers, Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Executable compresison, part II
Arkady V.Belousov escreveu:
I agreed: even if someone makes _real_ complain ("why you use my
proprietary compression program?"), then we may find workaround or we may
drop exepacking at all (especially because _this is not essential part of
program). Before this, I suggest, we may pack executables freely.
NOT AT ALL. Following SCO example, if we do that, _every_ FreeDOS user
could be sued. That would be catastrophic.
Alain
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] UPX/UCL Hell
Hi tom, IFF it's ok to compile a GPL program with any compiler of your choice, and distribute it, The problem is not the compiler but the library. On clear example is (in Linux) if you use GCC/GPP you can make a comercial program, but you cannot include it's _library_ because it's GPL. In this case a 100% free library CYGWIN exists to fill the gap. The point is that the code generated by the compiler is 100% free, but it cannot run without a libray... but nobody prevents someone else to make his own library ;-) MY INTERPRETATION is that if the library can be relinked by the user, then it can be distributed. So if the GPL part can be _replaced_ by one compiled by the user himself, it should be ok, but it seems that some people do not agree with me... :( Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Hi, I found this: chkdsk Ready 2003-10-6 I don't agree. If we have a fat32 kernel, and chkdsk is only fat16 we cannot use it :( There could be a reference to dosfsck, stating not compatible or something. Alain Aitor Santamaría Merino escreveu: I have committed most of the pending changes to the TODO list. While Jim and I acknowledge on the way of reintegrating it on the site, Bernd has kindly posted a preview of the list in the links below: 1.0 todo's: http://fdos.org/ripcord/fdos_1_0/official/todos.htm post-1.0: http://fdos.org/ripcord/fdos_1_0/official/post.htm --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
tom ehlert escreveu: himem /TESTMEM:ON|OFF really want a (bad) memory test in 1.0 ? As bad as is MS's is, it did save me many times. Consider it not a _test_for_100%_ok_ but as a _test_if_exists_ and you can understand how good it is. IMHO if implemented, it should be implemented with that functionality in mind. Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
A little more about memory testing: A good teste program must be very long, for one thing that nowdays memory are prone to random errors, not only repeatable ones. What I believe is usefull is something else: just check if it is there at all, if there are no holes (like the one at 16Mb inserted by some mis-configured bios), and other gross errors. That is more or less what the Bios "should" do. I agree more with Eric than with Tom (see bellow). Alain Eric Auer escreveu: > HIMEM /TESTMEM:... is indeed not that useful. An exist-check might be > useful, but a check like "write own address to all 0x?000 form > addresses" (to check if there is really RAM there and it is not > multiple copies of the first 16 MB or something) will probably be > useful to detect broken BIOS-hooking memory allocation schemes > without wasting much CPU time. tom ehlert escreveu: himem /TESTMEM:ON|OFF really want a (bad) memory test in 1.0 ? A> As bad as is MS's is, it did save me many times. Consider it not a A> _test_for_100%_ok_ but as a _test_if_exists_ and I disagree. If you want a memorytest (I don't question that), you can easily start one in autoexec; even HIMEM /TEST might be useful it's NOT intended to be a real memtest, but if you want one ... A> you can understand how good it is. if you understand how good it is (or _any_ other memtest) you have more information then I (and a VERY technical understanding of it) In fact I did have some information in memory tests, but that was a long time ago and probably a little outdated. Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: FreeDOS 1.0 TODO list ready (but not yet posted)
about fat32 testing: I believe a working DOSFSCK 2.10 just what is needed (not what is whished for). A ScanDisc-alike program would be nice, but IMHO what is really _needed_ is just some way of testing and fixing a fat32 disk, nothing fancy fust functional. This would give time to ScanDisk be implemented in any way that his author believes is best. As for 386 and memory requirements, we made some calculations here some time ago that 1) machines below 386 are not hardware compatible with disk worth using fat32, 2) due to bios limitations and machine evolution, if a bigger disk is possible then memory is almest often available. What would be nice though, is a smaller non-386 version for smaller systems, and we already have that. Eric Auer escreveu: Hi, some comments on your comments... CHKDSK is written with compatibility in mind even though it has several auto-activating cache builtin cache schemes. It looks like CHKDSK for the user, adds surface scan, and is 8086 compatible. CHKDSK of MS DOS does not support FAT32 - this is generally a task for SCANDISK at least in the earlier versions of FAT32-enabled Windows. In fact I believe that in the same version when MS introduced FAT32, it dropped chkdsk. The fastest way to write SCANDISK would be implementing [...] I believe it would be faster to make dosfsck work. and then... Last but not least it is useful to have TWO different ways to scan FAT12/FAT16 (because you can assume that both have different bugs, this will help finding the bugs in both tools). :) FreeDOS kernel should be MS DOS 3.3 but system should be MS DOS 6.22? I believe that we all just want to use FreeDOS in real machines for real applications. That requires a bit more than 3.3 In my opinion FreeDOS is comming to be a better than MS-DOS OS. DOS 6.0 not really - our EMM386 is limited, Not so much anymore :) MEMMAKER not existing at all, At the time it was really difficult to set everything. I believe it is easyer now (it has been for me) ;-) I might eventually get bored enough too add delayed writes and other gimmicks to LBAcache I would not use it :) , it is too dangerous (and maybe add a network drive > if you are willing to go that way, Andreas is working on an IP driver for DOS/Win/Linuix which is great (I am using it) and would be free for FreeDOS. I think we can call FreeDOS a clone of MS DOS 5.0 features with many goodies from later Win/DOS versions inside but with still a few DOS 5.0 features missing - some "legacy" ones do not hurt, > My point of view is: "can we use it to run the programs I want?" some others like Win 3.11 compat should probably be fixed before we call it FreeDOS 1.0 ... There is probably a patent to prevent us of it anyway :( Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] SCANDISK vs DOSFSCK
Aitor Santamari'a Merino escreveu: Luchezar Georgiev escribio': On Thu, 25 Mar 2004 20:08:32 -0300, Alain wrote: about fat32 testing: I believe a working DOSFSCK 2.10 just what is needed (not what is whished for). Actually, I agree! If Eric can say "FreeDOS SMARTDRV is LBACACHE", why not say "FreeDOS SCANDISK is DOSFSCK"? ;-) DOSFSCK is not a SCANDISK, but neither is LBACACHE a SMARTDRV! Well, I'd say this case is more restrictive. For LBACACHE one expects a commandline loadable program that acts as a disk cache. What people expects of SCANDISK is a user interface to disk scanning (otherwise why not rename it to CHKDSK32?). But if you add a UI to LBACACHE, why not rename it to SCANDISK, something the users are more familiar with? I disagree here: the important thing is to get the job done. After that if there is a nice interface, it can be great, but not essencial. In DR-DOS you only have one CHKDSK without UI. Why is the focus of scandisk on the interface I cannot imagine, even to the point of someone making an empty interface... ??? Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: SCANDISK vs DOSFSCK
Hi, The problem about all this discussion is that it is talking about DOSFSCK as if it has to be rewritten an debugged all over. That is not tha case. It is a _functional_program_ , it's kernel has no more known bugs (for what I remember). So if this missing function is added, very little testing would be needed ;-) Eric Auer escreveu: Hi, dosdosfsck-2.8-fat32 does work for FAT32 for me. IIRC it has bugs in the fat check/recover logic. Something about getting into a loop and something else about destrying Long Names. The problem with DOSFSCK for DOS in version 2.10 is that Imre did port the 2.8 -> 2.10 update but did not complete the disk I/O drivers yet, which is why I think that 2.10 for DOS works worse than 2.8 for DOS but has more potential (because it will have WRITE support - be able to fix errors). IIRC the problem is ONLY about one function to read/write sector beyond 2Gb. Eric, Do you have these functions that worked for 2.8? LBACACHE is similar to SMARTDRV.SYS I have been using it. It is really great. It really works :) As you know, I am happy that LBACACHE is not called SMARTDRV. And I think it is appropriate that DOSFSCK is not called SCANDISK. Agreed ;-) Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Kernel version
Johnson Lam escreveu:
I've an idea, as the official MEM of FreeDOS, is it good to include
the FreeCOM and Kernel information also?
I got a bit annoy because when I want to check Kernel version I have
to reboot, and I don't prefer to have another tool just check for
Kernel and FreeCOM.
I wrote some time ago a small program to show FreeDOS kernel version.
It really should be part of Freecom ;-)
it was tested in BC31. I have the .exe if you want it
#include
#include
#include
int main(void)
{
int i;
char far *p;
union REGS regs;
regs.x.ax = 0x3000;
int86(0x21, ®s, ®s); /* check oem-id*/
if (regs.h.bh==0xfd){
printf("FreeDOS detected: Int21/30 says OEM-ID=0fdh\n");
printf(" Dos verion = %d.%d\n",regs.h.al,regs.h.ah);
printf(" Kernel version %d.%d.%d\n",regs.h.ch,regs.h.cl,regs.h.bl);
regs.x.ax = 0x33ff;
int86(0x21, ®s, ®s); /* get version string */
p = (char far*)MK_FP(regs.x.dx,regs.x.ax);
if ( *(int far*)p == 0x7246) /* fast string checking "Fr" */
printf(" %Fs\n",p);
}else{
printf("NOT FreeDOS: Int21/30 says OEM-ID=0%02xh\n",regs.h.bh&0xff);
return !(regs.h.bh==0xfd); /* error level */
}
return 0;
}
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Kernel version
But VER /R of FreeCOM already does this! Typing VER /R gives: FreeCom version 0.82 pl 3 XMS_Swap [Dec 10 2003 06:49:21] DOS version 7.10 FreeDOS kernel version 1.1.33 Ok, but: 1) never dreamed of typing VER /R or VER /? _this extended version should be the dafault_ 2) Kernel version only by numbers is not enough, there are too many variants that show only in the kernel description string string (like fat32) Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Kernel version
Bernd Blaauw escreveu: 1) never dreamed of typing VER /R or VER /? _this extended version should be the dafault_ that may be not so compatible to batchfiles etc. VER /R is an ancient trick. This will *not* be incompatible because this is just a text output. only difference in that it is a little bigger. M$'s also vary a lot from one to another and I dont believe someone made a parser for that ;-) 2) Kernel version only by numbers is not enough, there are too many variants that show only in the kernel description string string (like fat32) Kernel 2033 [FAT32, 2004-04-01-CVS, OpenWatcom1.2, UPX1.24-NRV] (not everything can be set. for example, UPX only happens after compiling the kernel.) Whith that I van usualy identify one and find it again or information about it. Luchezar Georgiev escreveu: > This is shown on kernel startup. The DOS Function 30h code is > (inthndlr.c, line 696) > >/* Get (editable) DOS Version */ > case 0x30: >lr.AL = os_setver_major; >lr.AH = os_setver_minor; >lr.BH = OEM_ID; >lr.CH = REVISION_MAJOR; /* JPP */ >lr.CL = REVISION_MINOR; >lr.BL = REVISION_SEQ; There is also one other for DR-DOS and something (which I don't know) for Datalife-ROM-DOS. But specificaly for FreeDOS it is not enough because there are far too many versions with the same numbers :( Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Kernel version
Hi Lucho. There is also one other for DR-DOS and something (which I don't know) for Datalife-ROM-DOS. Right. I posted the ROM-DOS one at the kernel mailing list last year. Do you have it handy to send it back to me? I hava a dos version program and I do have a rom-dos and I would like to test it. You've always been honest to me so I'll be honest to you, too. I'm too busy/lazy/whatever to implement this, so here's an excuse: "Please redirect your request to FreeDOS-kernel mailing list" ;-) Never mind, I will do it some day To be even more honest (cynical?), I don't care about anything but FAT32/80386 kernels. But fortunately, Bart is not like me ;-) In fact my focus in on that too :) Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Ralf Brown's interrupt list 62 will never be released?
P.S. Under what license was the RBIL released? What about an ABIL (Arkady Belousov's Interrupt List)? ;-) What about puting somwhere an APTR (Arkady's patchews to Rbil)? He just said in a message that hes has his own collection do you agree, Arkady? Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] HIMEM64 - KBC
tom ehlert escreveu: LG> send me a binary to test at lucho gawab com here are part of the headers, which I get forwarded from SF From: Luchezar Georgiev <[EMAIL PROTECTED]> I seems that you have to hide you adress better ;-) Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: FreeDOS Beta9 RC5 has been released
Bart Oldeman escreveu: How about speed gain? Perhaps, sometimes 1, 2 or 3 more BUFFERS available can make a difference. Otherwise I can't see any visible speed difference. I did som testing some time ago (M$DOS) and my conclusion is that if other buffers are present (in my case smatrdrv and internal cache) it is best _not_ to have too much buffers, no more that something between 10 and 20. In my case I limited to 10, but I remember som Windows problem if buffers were <20, but that could be in wfw3.11... Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] TDSK with EMM386 function 58h fix
Arkady V.Belousov escreveu: Hi! 20-Апр-2004 15:26 [EMAIL PROTECTED] (Michael Devore) wrote to [EMAIL PROTECTED]: MD> Big question for you, and any other interested parties: Do you want me to MD> hold this version EMM386 and see if any other problems shake out of the MD> tree, or make it available immediately? I think, for bugfixes you should release immediately. :) I Agree Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] OT: Problem with C-compilers and #if
I hope someone here can help me with these conditionals: #ifdef NET_ABP #if NET_ABP == 1 ... #else ... #endif #elif NET_TCP ... #endif In fact they get a lop more intermixed than this. What happens if I write #if NET_ABP == 1 and NET_ABP is not defined? or even #if defined(NET_ABP) && NET_ABP == 1 this works in C, but would it work with compilers? I have in mind Borland C (3.1 and 4.52) and Watcom C thanks for any help :) Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] OT: Problem with C-compilers and #if
Arkady V.Belousov escreveu: Hi! 22-Апр-2004 15:25 [EMAIL PROTECTED] (Steve Nickolas) wrote to [EMAIL PROTECTED]: Standard says: if name not defined, it replaced by 0. Consequently, you may use first condition: #if NET_ABP == 1 Thanks. SN> I would've thought that SN> #ifdef NET_ABP SN> #if NET_ABP == 1 SN> /* ... */ SN> #endif SN> #endif SN> would be safer... Only if you find somewhere compiler, which advantages will cover its buggines. PS: Most reliable method agains bugs is not turning computer on. :) Even better is removing that part that is between the keyboard and the chair ;-) Alain --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] HIMEM64+EMM386
Hi Michael, I just Tested HIMEM64+EMM386 in a Texas (aka Acer) Notebook Extensa 502DX with a Pentium 266MHz with 64Mb Ram. The purpose of the test was that it has a PCMCIA ethernet card that needs a HOLE in memory. I used ALL M$DOS stuff, except for the test programs. My config.sys: device = c:\fdos\himem64.exe device = c:\fdos\emm386.exe noems x=cc00-cfff ... Worked 100%, including my DOS4GW 3Mb programs. Thanks veeery much for the fine program. I will run more tests today... Question: Why does HIMEM64 have a .EXE extention? I allways thought that a .exe device driver was more dificult? (just curious ;-) ) Alain PS: I am really impressed, specially by the speed that you can turn up with fixes ;-) --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] HIMEM64+EMM386
Hi Michael, I just Tested HIMEM64+EMM386 in a Texas (aka Acer) Notebook Extensa 502DX with a Pentium 266MHz with 64Mb Ram. And ecverything else M$DOS 7.10 More tests: allways does a cold-boot with memory test. Maybe you intend it to be soo, but it is non-standard behaviour. Alain --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] HIMEM64+EMM386
Hi Michael, I am not sure that I understand what you said: 1) I understand that _some_ old hardware had a reset bug (or wasit an old emm386?) 2) I tested in real mode, just after the autoexec completed. BUT, from what you said if a happens in protected mode, then it looks like a great idea making a cold boot. BTW what if I am running a protected mode program that just switched to realmode for an ISR or to access DOS? Anyway, most new chipsets have reset bugs. Very oftenly after exiting windows 98se some things don't work. As an example int taht Texas notebook, one bit in the serial interface stops working, iirc the break detect. Alain Michael Devore escreveu: At 11:05 PM 4/22/2004 -0300, Alain wrote: Hi Michael, I just Tested HIMEM64+EMM386 in a Texas (aka Acer) Notebook Extensa 502DX with a Pentium 266MHz with 64Mb Ram. And ecverything else M$DOS 7.10 More tests: allways does a cold-boot with memory test. Maybe you intend it to be soo, but it is non-standard behaviour. Always did, or would have had there not been a OUT port bug in the original EMM386 reboot routine that was fixed. I don't know why it was originally set it up that way, but hard to believe it was done without a reason. But I'm seriously thinking about adding explicit warm boot flag into the Ctrl-Alt-Del handler, removing the OUT port reset there, and letting :0 real mode BIOS address handle things. I suppose it's possible the original coder thought things could be so munged up that the reset to real mode from protected mode might fail before :0 access and cause lockups, but that's not much different from other types of crashes which mess the PC's mind up so badly you have to hit the reset switch anyway. Can't think why else you'd want a POST to happen. --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] HIMEM64+EMM386
Hi Michael, I'm not sure why it matters if the Ctrl-Alt-Del happens in protected mode application. The only difference I can detect between warm and cold boot is the cold boot has the POST memory check and resets the hardware, which is annoying to wait for when it isn't required. That's true in either real or protected mode. Do you meen ther usualy Warm-Boot dos not do a reset? I allways understood that that the only thing that is skipped is the memory test, not the hardware reset... Alain --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: FreeDOS Beta9 RC5 has been released
Just one question: How much does MODE grow with Zlib? And one more: What about an install program that extracts needed information from a standard .zip file specific for that user's needs? Alain right now on updated ODIN bootdisk the CPI files take almost 600KB (10 * 60KB), which is nearly half the disk! (and makes creating 720KB more difficult). --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Rainone offering Italian translation for FD
Eric Auer escreveu: Again, I suggest to ask Francesco to translate the FreeCOM shell message catalogue first. Hope that is a good idea... Good Idea. I have parttially fixed FreeCom in pt_BR (Brazil), but it is 2 or 3 versions late and the previous version althoug very good, did't have any accents. I will some time soon release a new version. If anyone is interested, contact me ;-) Alain --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: ANNOUNCE: Edit 0.81
Eric Auer escreveu: Hi Joe, thanks for all the changes! Still some comments... 2) Title bar mentions 0.7a, but not 0.8. -- If you want to know what version you're using, go to Help|About. Maybe, but version in title bar is easy to implement and reminds people which version they use, good for bug reports. I believe that he is right ;=) Alain --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Rainone offering Italian translation for FD
Aitor Santamaría Merino escreveu: Hi, Alain escribió: Eric Auer escreveu: Again, I suggest to ask Francesco to translate the FreeCOM shell message catalogue first. Hope that is a good idea... Good Idea. I have parttially fixed FreeCom in pt_BR (Brazil), but it is 2 or 3 versions late and the previous version althoug very good, did't have any accents. I will some time soon release a new version. If anyone is interested, contact me ;-) Just in case it helps, in the header info I have recorded (as a comment) for future references the codepage in which the catalog file has been made with. Ok, but by the functions that were missing, the version I started with was several years old so probably at the time there was no codepade at all. That is probably why it was intentionaly done withou accents Alain --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM German translation fix
Eric Auer escreveu: After this has been done, I would like to take my file offline again. If you want to offer a FreeCOM binary in German language online: Fine, but please create a proper zip with the same contents as the English binary zip, not only the pure undocumented .com file. I feel that all the international binaies of FreeCom should be kept online somewhere. Most users are non-programers and I feel it can be alittle over-complicated for them. Who has an opinon about this? Alain --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: FreeCOM German translation fix
Eric Auer escreveu: Hi, the localization of the precompiled FreeCOM is basically simple: Should be. But it took me more than one day to build the portuguese version. Why? because it was incomplete, I had to add many strings, change many others, etc. I am a programer, so it was not so difficult, but a normal user could not do it. If someone makes a binary, at least it will be tested and useable. Alain --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: hardware database
Network cards: FreeDOS does not come with drivers. So if your network card comes with DOS drivers, fine. Else: Not fine. There are generic drivers for NE2000 compatible cards, though. I have the full collection of Packet-Drivers, so that if the Cirwin site goes off line, we can upload it somewhere... Alain --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: [Freedos-cvs] kernel/kernel fattab.c,1.30,1.31 fatfs.c,1.66,1.67
Bart Oldeman escreveu: don't pay too much notice. This is just standard ritual. Scary thing is that it's being going on pretty much the same way for three years now. Time for me to unsubscribe from the mailing lists and have a break from FreeDOS. Please Bart, don't. We have already lost Lucho for no more than this. Maybe things could get a bit more polite around here, or whatever it takes to keep good helpers from fleeing :( Alain PS: A very sad alain --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANNOUNCE: FD APPEND 1.0
Hi Aitor, Can I use this append with MS-DOS or in Win98se dos-box? thanks for this, Alain Aitor Santamaría Merino escreveu: Hi all, I'd like to announce FreeDOS APPEND 1.0, a very basic APPEND that I have created. With this, I could run WordStar Express in a mixed directory installation, as I intended. APPEND 1.0 is very basic. In particular, it is NOT implemented: - APPEND /E - FCB functions - The function 11 of the API You can get it from here: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/append/aappend.zip (not to be confused with the other file present there). Regards and enjoy, Aitor --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANNOUNCE: FD APPEND 1.0
Arkady V.Belousov escreveu: Hi! 21-Май-2004 23:07 [EMAIL PROTECTED] (Aitor Santamarэa Merino) wrote to [EMAIL PROTECTED]: ASM> I mention this of backdoors in particular because: ASM> (a) MS-DOS 6.22 help does say that COMMAND's DIR is not affected by ASM> APPEND /X. FreeCOM DIR is not affected by FD-APPEND /X, even with no ASM> modification on the side of FreeCOM How to overcome presence of APPEND? I mean, APPENDed names, probably, may/should be ignored by ATTRIB? I believe that attrib uses findfirst/findnext that is not affected, and append affects only file opens... Am I right? Alain --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANNOUNCE: FD APPEND 5.0 v0.4
Is this append FreeDOS only or should it run in MS-DOS 7.10 or in a Win98 DOS-BOX? Alain Eduardo Casino escreveu: Hello All, This fixes a nasty bug, so upgrading is recommended for everyone. Most important changes from v0.1 (v0.2 announce got lost and v0.3 was never public): * Fix hang when switches appear before the path in the command line. Thanks to Bernd Blaauw for reporting this bug. * Make it compilable with older versions of Nasm (Eric Auer) * APPEND is now a COM file (smaller), as suggested by Eric, but it keeps the EXE extension. See history.txt for all the changes. You can download it from: Source: http://perso.wanadoo.es/samelborp/appe504s.zip Executable: http://perso.wanadoo.es/samelborp/appe504x.zip Please, report bugs to Bugzilla. Eduardo. --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANNOUNCE: FD APPEND 5.0 v0.4
Arkady V.Belousov escreveu: Warning: unlike .COM, for .EXE DOS doesn't places zero on top of stack, so, you can't end .EXE program (plain .EXE or converted from .COM to .EXE) by RET instruction, only by INT20 or INT21/4C. What is the default for Borland Compilers? do you know? This is probably a very usefull information ;-) Alain --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] bug in UMB support
tom ehlert escreveu: if the a000 block is ever merged into the lower memory area, interesting things might happen. I remember one for instance: it was possible with a MDA to have 704k lower memory. Not interesting anymore, after the advent of VGA. So, my vote is that any workaround is as good as a fix for something that will never get used ;-) Alain --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] bug in UMB support
Arkady V.Belousov escreveu: Hi! 21-Июн-2004 18:37 [EMAIL PROTECTED] (Alain) wrote to [EMAIL PROTECTED]: if the a000 block is ever merged into the lower memory area, interesting things might happen. A> I remember one for instance: it was possible with a MDA to have 704k A> lower memory. Not interesting anymore, after the advent of VGA. Why? Expanding base memory over VGA graphics segment is a nice feature. I cannot figure many situations where VGA without Graphics can be usefull. Let me say it otherwize: the only programs that I know of, that need more LowMemory are graphics ones... Alain --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] bug in UMB support
Arkady V.Belousov escreveu: ? _Now_ behavior of FD is same as with MS-DOS (ie. it not hangs when base memory size is more than 640k after loading some driver). I must agree that he has a point here ;-) --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] PSP as storage area in a TSR
Eduardo Casino escreveu: Hello All, Can anybody tell me if there is something that prevents using the _whole_ PSP as an storage area in a TSR? I mean within the TSR extension itself, I know the limitations when executing a program. I remember that some TSR did a little of that in the old days, I remember that the second half is save (command line buffer) Alain --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FORMAT 0.91p released
Hi Eric, I just tested new format in a Win98 Dos-box. It reports an error: -1--- D:\FreeDos\!MyVer>FORMAT.EXE a: /u Could not lock logical drive (error 0x5)! Aborting. -2--- D:\FreeDos\!MyVer>FORMAT.EXE a: /u /d [DEBUG] This is FORMAT 0.91p, selected drive -> A: [DEBUG] DOS 7+ detected, LOCKing drive. Could not lock logical drive (error 0x5)! Aborting. -- I believe this is very Windows specific, but if you are willing to try, I am willing to test Alain Eric Auer escreveu: Hi, I have improved FreeDOS FORMAT again: http://www.coli.uni-sb.de/~eric/stuff/soft/by-others/ format-0.91p.zip (134k, and I think that < 50% "by-others" is left in there after my changes...) --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 VCPI/DPMI Help / Question
Yes, I remember that Tom was not willing to add VCPI _himself_ and no-one volunteered for the job befor Michael. Oh! there was a lot of people saying that it _should_ be this way or the other, but noone volunteered to do it. TRUE. Alain tom ehlert escreveu: > be you have difficulties with the english language, but there is a huge and significant difference between 'idea to add VCPI' and 'idea that tom ehlert adds VCPI' :) --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] A000 to A001 possible change
Hi Michael, If you want a vote, the question that comes to my mind is: HOW CAN WE TEST IT? I personaly will not use it, and don't know of any situation where this could be used. I DID use it in the past, very distant past, with Hercules Graphic Adapter. But where coul I find one of those? Alain Michael Devore escreveu: At 06:56 AM 7/7/2004 +0200, tom ehlert wrote: Hello Michael, > Should EMM386 remove its current code which changes returned upper memory > block start addresses from A000 to A001? Is it safe? Is it sane? Is it > The Right Thing To Do or not? when I wrote that 'return a001 instead of a000', I saw a lot of problems, that would arise, if lower memory MCB's will ever be joined to a000 UMB memory. so I decided to intentionally return a001. IMO this might be feasable, if the kernel knew about a000, and immediately merged completely into lower memory arena, and start UMB at c800; else strange things *will* happen. neither KE2035 nor toms KE2035+ kernel care about a000, and will probably behave somewhat different from specification. Alright, I'm a bottom-line kind of guy. Do you think we should A. remove the A000 -> A001 code (Arkady preferred) or B. not remove the A000-> A001 code (status quo) or C. don't care? I'm neutral unless more than one other person supports removing the code. --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: EMM386 VCPI/DPMI Help / Question
Hi Michael, I would like to give you my opinion about the RAM option: I USE IT !!! And I have two reasons to use it: 1) it is easy and works on any machine and then I can just leave it working and go home :) 2) on NEW HW it works fine. In modern machines (mostly from PCI and P133 up) upper memory area is not encombered with anything. Before that QEMM's optimiser was the only way to make good use of UMB, but now any conservative auto setup will just set one chunk that goes from the video ROM to the BIOS ROM and that is just as good as you can get !!! ==>> I am talking of many years of experience and surely there will be exceptions, but I have seen only one in all this time. So this makes me VOTE for the RAM option ;-) thanks for your patience, Alain Michael Devore escreveu: At 07:00 PM 7/6/2004 +0200, Aitor Santamaría Merino wrote: By the way, it's long since I last watched the EMM sources, but I've always thought that implementing RAM=/I=/X= couldn't be very difficult with current sources, by just modifying a bit ScanSystemMemory(), the current search range is fixed (at least it was in 2003): for (mem = 0xc000; mem < 0xf000;) /* This is the range that should be IMHO modified with RAM= */ so you'd process the I's first, the X's next, and lastly the previous loop, so that if the entry is empty (hasn't been filled by the I/X processing) then you scan. Well, the fact that it might not have been done like that by current EMM386 developers gives a clue that it must be something more difficult behind... or am I wrong? Most standard options aren't all that horrible to implement, they just take modest chunks of time one by one, with debug and verification/field testing usually taking a lot more time than actually coding them. Now we have active RAM and HIGHSCAN requests, no big deal for either, really. But I'd like to see what the timeline for 1.0 FreeDOS release is first. The ever-receding goal line is getting me down. --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: EMM386 VCPI/DPMI Help / Question
Hi Michael, I am 99.9% sure thar without RAM there is no UMB. I will check it tomorow. Alain Michael Devore escreveu: At 01:08 PM 7/8/2004 -0300, you wrote: Hi Michael, I would like to give you my opinion about the RAM option: I USE IT !!! And I have two reasons to use it: 1) it is easy and works on any machine and then I can just leave it working and go home :) If you are using RAM without any parameters, EMM386 should not behave any differently than if it didn't exist. Standard UMB area scan occurs whether RAM is there or not. Only the optional range with RAM makes a difference, changing the default scan area size. And if you know your non-default range that well, why not just I= include and X= exclude within it? I still see scant evidence that RAM is anything but a weak option needed almost solely for minor MS-DOS compatibility sake. For compatibility reasons alone RAM should be in there, but not as a pressing issue. Same deal with HIGHSCAN and others. What makes the grade for adding to the option list right now, as a user-driven priority need? --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: EMM386 VCPI/DPMI Help / Question
Bernd Blaauw escreveu: Alain schreef: 2) on NEW HW it works fine. In modern machines (mostly from PCI and P133 up) upper memory area is not encombered with anything. Before that QEMM's optimiser was the only way to make good use of UMB, but now any conservative auto setup will just set one chunk that goes from the video ROM to the BIOS ROM and that is just as good as you can get !!! ==>> I am talking of many years of experience and surely there will be exceptions, but I have seen only one in all this time. Alain, you must be having a simple machine with no option roms then :) SCSI takes UMB space, and so do PXE ROM, SerialATA controller, etc. my last machine only had 4KB UMB space or so.. Yes, almost all are simple machines. For normal corporate lowcost workstation. SCSI never, PXE I don't know what this is, SerialATA didn't come around until now. I try to KIS ;-) Alain Bernd --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] GRC and FreeDOS
I believe this is a very typical representation of FreeDOS development. Some people are optimizing it while critical problems (for some people) remain unsolved. Gregory Pietsch escreveu: I got this in an e-mail that was also sent to Steffen Kaiser. I haven't included Roland's e-mail address per the note -- Gregory: Hello, do you know that Steve Gibson(www.grc.com) is "Considering spending $20,000 for DR DOS"? There is a thread about this in news.grc.com/grc.spinrite.dev. He is still using FreeDos, and maybe he would be willing to invest some money into FreeDos if you would fix the problems he is is currently having with it. If you are interested go to the newsgroup and participate in the conversation. Also forward this email to other freedos developers if it's useful, but please remove my email address if you are going to post it in the mailing list, I don't want more spam. Roland -- "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] GRC and FreeDOS
tom ehlert escreveu: Hello Alain, I believe this is a very typical representation of FreeDOS development. Some people are optimizing it while critical problems (for some people) remain unsolved. I don't think that this statement is valid for the last 3 years of kernel development. tom Not from you, but from some people yes :( Alain --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: best free C++ compiler
Only TC 2.01 and TC++ 1.02 are free. And OpenWatcom! Quite big but seems to be quite powerful as well. ... And note: TC/TC++ are free as in beer (zero cost.) But they are not "free as in speech" - source code is not available. IMHO it is not free. it says only for Personal Use. This makes devellopment even of FreeDOS utilities theoreticaly forbidden ... Alain PS: FWIU the later Borland museum compiler is BC1 that was released _after_ TC2, but for mistirious reasons I posted this many-many times and I fell into a some void. Well, now we know for sure that information is not lost in black holes (see Stephen Hawkings :) --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: best free C++ compiler
Gregory Pietsch escreveu: Why would development of FreeDOS utilities be forbidden? Nobody is requiring that anyone actually use TC 2.01 or TC++ 1.02. As long as the written code is portable, it should work with any compiler. ;-) If the licence says "for personal use only" or something like that, it probably does not apply to FreeDOS which is wildly distributed. It does not say "and for GPLed software". Borland is not _likely_ to sue us, but better be on the safe side. Anyway the advantage of a 100% free compiler like OpenWatcom is that it can even be distributed with FreeDOS (in the CD version) and it should make life easyer. Alain --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: best free C++ compiler
Arkady V.Belousov escreveu: Hi! 22-Июл-2004 21:24 [EMAIL PROTECTED] (Alain) wrote to [EMAIL PROTECTED]: A> PS: FWIU the later Borland museum compiler is BC1 that was released A> _after_ TC2, but for mistirious reasons I posted this many-many times A> and I fell into a some void. All see your mentions, but TCPP1 is very buggy and outdated beast, which better not to use. ?? I said BC and not TC ?? Please confirm this is buggy too. ( I remember that you colect information about that issue :) BTW: do you have information about memcpy() problems in BC 3.1 ? Last week I had a very hard to trace bug (in a TSR) that was solved replacing it with memmove(). Andreas sayd that he had problems with it too. Alain --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Kernel 2035/2035a versus FreeCOM
FreeCOM uses direct hardware access to beep in TAB completion, maybe THAT hangs your system. The problem not happening in my PC but in office PC, maybe you're right, in office PC press TAB will have a long beep and hangup Well, I use direct HW access for beep for many years and in many machines and never detected a problem. Mostly I use BC31 sound() and nosound(), but I made my own too, theoreticaly equivalent and installed in over a hundred assorted machines. Does someone know how FreeCOM does this so that I can compare? Alain --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: best free C++ compiler
Arkady V.Belousov escreveu: A> BTW: do you have information about memcpy() problems in BC 3.1 ? Last My BC bugs list contains: - Result of intrinsic-version of "memcmp" function undefined when third argument is zero. FIX: check size of compared memory blocks before "memcmp". Probably, memcpy() contains same bug. Which one you mean? I mean mamcpy(), but I will check it it could possibly have the 3rd argument =0. thanks. Alain --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Re: Kernel 2035/2035a versus FreeCOM
Hi Eric,
I don't remember ever having problem with those sound() functions. In
fact the time I thought I had, I made my own functions end the problem
was NOT there ;-)
Alain
Eric Auer escreveu:
Hi Alain!
FreeCOM uses direct hardware access to beep in TAB completion,
maybe THAT hangs your system.
Apart from that, the direct access style beep is MUCH too long in DOSEMU.
void beep_low(void)
{
sound(900);
delay(400);
nosound();
delay(100);
}
void beep(void)
{
sound(900);
delay(400);
nosound();
delay(100);
}
I only had 0.82pl1 sources around, not sure what 0.82pl3 or even 0.82pl3w do.
Looks like library functions from the compiler - hopefully NOT using a
compiler which has broken delay() !?!?
Would be better to use the 40[6c] timer tick counter instead.
Eric
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Freeware CHKDSK with FAT32 support
I am VEEERY glad to hear this :))) Alain Eric Auer escreveu: Hi, I would like to comment that I am planning to improve the DOS port of dosfstools DOSFSCK 2.10 next month, which should give us an open source FAT12-FAT16-FAT32 filesystem checker This could be improved by wrapping everything into a SCANDISK-style user interface and a function to store a binary change log to an "undo file" if the user wants to create one. That is sugar. Not Needed. If the standard interface is 100% functional it is THE most important thing. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Ensemble Lite Redux
I sent a compiled beep program, but I have not seen my message in the list. did it get thrugh? Alain Eric Auer escreveu: Hi, I vote for Bernd's idea: Make ALTBOOT an ignored option - at it would enable the behaviour which FreeDOS EMM386 has as default anyway - and introduce a NOALTBOOT option which suppresses INT9 (keyboard) hooking. Apart from that, "/" in front of options could be treated as optional, to allow more "flexible" command line syntax. Eric PS: About the tab-completion-beep problem in FreeCOM: I think this is really a FreeCOM (C compiler library delay/nosound/sound) problem with Johnson's hardware. So it probably even happens in MS kernel. I think the kernel has no influence on this at all. A test program would just produce a beep :-). --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] BEEP
Yes, FreeCOM has to work over serial lines. In embeded this is used.
Alain
Luchezar Georgiev escreveu:
Hello Bart and Tom,
Don't forget that FreeCOM is also supposed to be able to run over a
serial line via CTTY. In that case the beep should happen on the
terminal and not on the PC where FreeCOM actually runs.
So I vote for
putchar('\007');
no BIOS, no int29, no delay timing, no direct hardware, just keep it
simple -- the ASCII beep goes to STDOUT, redirected to STDAUX and
beeps at the right place.
You're right, Bart! I vote for putchar('\a') too! ('\a' is the C
"alert/bell" character, ASCII 7.)
in that case, I vote for MS compatibility: don't beep at all.
But MS COMMAND.COM before XP doesn't do autocompletion at all. The XP
and Windows 2003 COMMAND.COM copy the 4DOS behaviour (just display the
next matching name on each TAB key press, and beep only if there are no
matching names). But FreeCOM copies the "bash" behaviour - beep on the
first TAB key press and show all maching names on next TAB key press.
Where is the MS compatibility here?
(the default BIOS beep is really dull)
But it's definitely better than a fancy beep hanging the machine. And an
'\a' character sent to the console is the only way to make a teminal
sound, as Bart points out.
Regards,
Lucho
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32RTM Bug Found, no good fix
Hi Michael, Thanks very much for the debugging... IMHO this is a case of needed "bug for bug" compatibility :( I say needed because there are _A_LOT_ of Borland programs around. It would not be needed if it happened only in an obscure rarely used program. I can even argue that FreeDOS is Beta, that is because things may change, this is as good an example as anyone can get. Alain Michael Devore escreveu: [Sorry, this is going to be long. I can't describe the problem properly otherwise. I'm cc'ing to devel since the problem isn't really in the kernel and affects all Borland 32RTM users.] The 32RTM problem where 32RTM executing under FreeDOS without the -X option generates an exception is a Borland bug. And the bug only shows up with FreeDOS because MS-DOS does something slightly different, although the FreeDOS method is perfectly valid. The problem occurs in this code segment in 32RTM: push bp sub sp,32h mov bp,sp mov word ptr [bp+1ch],3400h mov word ptr [bp+20h], 3202h mov word ptr [bp+30h],0 mov word ptr [bp+2eh],0 mov ax,300h mov bx,21h mov di,bp push ss pop es int 31h Briefly put: when the int 31h (DPMI interrupt) occurs, 32RTM generates an exception under FreeDOS. Basically what is happening in this code segment is that 32RTM sets up a stack frame to hold a real mode call structure pointed to by ES:DI for calling INT 21h through the INT 31h DPMI interface. It sets the AX value to 3400h, for get InDOS function. The 3202h value is the flags register. And the 0 in the other two stack frame values indicates that the DPMI server should use its own internal stack. Everything other real mode register is don't care. The ax,300h simply is the DPMI function for simulate real mode interrupt, here to call INT 21h function 34h. Okay, hope that's clear. People who use DPMI functions might notice one small omission here. No CX register value is set. Well, CX is an important register for the 300h function, it is the number of words to copy from protected mode to real mode stack when the interrupt is issued. So I looked further back in the 32RTM code to see where CX register is getting set and falling through to this routine. Amazingly enough, the CX value used is the one that is returned from an earlier real mode INT 21h function 30h get DOS version call. The return value of CX from that function is the lower 16-bits of the "user serial number", whatever the heck that is. Unfortunately, FreeDOS returns a serial number of 101h in CX. MS-DOS appears to return a value of 0. By a fluke, MS-DOS is returning a CX value which allows the above DPMI call to function without problems. So what happens with the FreeDOS 101h value in CX? It copies 514 bytes of crap to the real mode stack during the INT 31h. That blows the DOS stack right there, and if it doesn't, it sure blows the internal DPMI stack. Hard to say what important internal data gets shot down with the copy. How do I know this is the problem? I tested it two different ways: First, I in the debugger I dynamically patched the: mov word ptr [bp+30h],0 mov word ptr [bp+2eh],0 instructions in the code fragment to: xor cx,cx mov [bp+30],cx mov [bp+2eh],cx with NOP padding. 32RTM happily went resident without exception, since no bytes were copied to and from the real mode stack. Second test: while in the debugger, after the 30h get DOS function call in 32RTM, I changed CX return value from 101h to 0. Once again, 32RTM went resident without problems. There you have it folks. A dumb bug in a Borland product that by purest happenstance fails under FreeDOS and not MS-DOS. I don't have any idea how to gracefully fix the problem other than to have FreeDOS change its serial number. And it shouldn't have to do that. --- 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 --- 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
[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] Re: Idea about Virtual PC compatibility / A20 handling
Hi Michael, I believe that you made you position cristal clear. Not only I respect that but I agree with it. And many thanks for what you have done so far :)) But, (is there always one?) does the "RAM" option fall within "a compatibility problem"? I use it as default for one reason: I install it on any client machine and I don't expect it to do any optimization, but to provide _some_ UMB which ususaly makes a better system as a whole. Alain Michael Devore escreveu: At 08:02 PM 8/23/2004 +0200, Eric Auer wrote: "Conclusion": I wrote to the list, suggesting that this might be an A20 related problem, and suggesting to re-add Tom's invention, the "refuse to actually disable A20", to HIMEM (or EMM386: at least MS EMM386 locks the real A20 to on and uses the paged memory system to SIMULATE a (fast) switchable A20 for DOS), but not (as for Tom's version) as a compile time option but as a command line switch. The only new options and features I will add to EMM386/HIMEM at this point in the FreeDOS release schedule are those which are know to correct an error or fix a compatibility problem. "Known" means exactly that. It does not mean: theorized, guessed, posited, hypothecated, assumed, suggested, or run up a flagpole to see what salutes. The last two features to EMM386 were SB to give it SoundBlaster compatibility -- which DOES work with SoundBlast emulation by the way -- and ALTBOOT to fix an incompatibility with BreadBox/GEOS's Ensemble. If, and only if, a problem occurs with an application that requires a new feature as verified by me will I personally add such a feature. Naturally, you may convince Tom or someone else to add the feature in the absence of such verification, just not me. Verification needs to be either by my testing here or via a reasonably detailed explanation by a reliable source as to why the feature is desired or necessary. Alternatively, if you have incontrovertible proof that a new EMM386 option is vital to prevent space aliens from irradiating the earth with their king-sized jello ray and converting all life forms to gelatinous cubes, I'd like to see that. I still won't add the option, but looking at the proof should be a hoot. And finally, should one of us send me a private e-mail explaining why my position is incorrect, how I am Not Doing The Right Thing, and why FreeDOS suffers mightily under my personal development restriction, I feel certain that I shall develop a mysterious case of hysterical blindness and fail to read its content. Fortunately, I am sure the condition will clear up soon thereafter. --- 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 --- 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] Re: Idea about Virtual PC compatibility / A20 handling
Michael Devore escreveu: But, (is there always one?) does the "RAM" option fall within "a compatibility problem"? I use it as default for one reason: I install it on any client machine and I don't expect it to do any optimization, but to provide _some_ UMB which ususaly makes a better system as a whole. RAM should work as of last or last+1 EMM386 unless you mean with a range. It's basically a null option with FreeDOS, though. Is that what you're asking me, or am I missing the question? Not exaclty, I meant not as a NULL option for compatibility only, but as not-so-smart-but-functional option in that doesn't go over the head to get all available memory, but anything that is both easy and safe like one big block just below the bios or whatever. My basic assuption is that on most machines this is just fine, but when I posted a comment about that here some time ago, I remember some arguments that this is not so good any more and the latest ones with Serial-ATA and other things consume most of UMB :( Alain --- 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] EMM386 options, was: Idea about Virtual PC compatibility / A20 handling
Michael Devore escreveu: At 04:30 PM 8/24/2004 -0300, Alain wrote: Michael Devore escreveu: But, (is there always one?) does the "RAM" option fall within "a compatibility problem"? I use it as default for one reason: I install it on any client machine and I don't expect it to do any optimization, but to provide _some_ UMB which ususaly makes a better system as a whole. RAM should work as of last or last+1 EMM386 unless you mean with a range. It's basically a null option with FreeDOS, though. Is that what you're asking me, or am I missing the question? Not exaclty, I meant not as a NULL option for compatibility only, but as not-so-smart-but-functional option in that doesn't go over the head to get all available memory, but anything that is both easy and safe like one big block just below the bios or whatever. My basic assuption is that on most machines this is just fine, but when I posted a comment about that here some time ago, I remember some arguments that this is not so good any more and the latest ones with Serial-ATA and other things consume most of UMB :( I could map RAM to X=TEST which is about as safe as you can automatically get for UMB's, but that would appear to break MS compatibility for RAM option. What the heck does the documentation stating that RAM option uses "all available adapter space" mean anyway? Is RAM supposed to be strictly an A000-B7FF inclusion, e.g. I=A000-B7FF? My help (from MS-DOS 6.22) does not say that, loosely retranlating to english it says "EMM386.EXE will use all available extended memory for UMB". This is not a good explanation either. I always understood that it is suposed to get all "normal" areas. As far as I remember it gets UMB between the Video Bios and the Main Bios. With graphics mode, the A000-B7FFF is not usefull anyway. Let's put it the other way around: What do you recommend for basic automatic UMB enabling (and eventualy nothing more)? Alain --- 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] EMM386 options, was: Idea about Virtual PC compatibility / A20 handling
Michael Devore escreveu: At 05:45 PM 8/24/2004 -0300, Alain wrote: Michael Devore escreveu: I could map RAM to X=TEST which is about as safe as you can automatically get for UMB's, but that would appear to break MS compatibility for RAM option. What the heck does the documentation stating that RAM option uses "all available adapter space" mean anyway? Is RAM supposed to be strictly an A000-B7FF inclusion, e.g. I=A000-B7FF? My help (from MS-DOS 6.22) does not say that, loosely retranlating to english it says "EMM386.EXE will use all available extended memory for UMB". This is not a good explanation either. I always understood that it is suposed to get all "normal" areas. As far as I remember it gets UMB between the Video Bios and the Main Bios. With graphics mode, the A000-B7FFF is not usefull anyway. That would put RAM back to its current behavior, which is NULL or in other words, do the default FreeDOS behavior of map all available extended memory, i.e. those not signed as ROM or used as EMS page frame. Let's put it the other way around: What do you recommend for basic automatic UMB enabling (and eventualy nothing more)? X=TEST. Still can't catch everything out there and may be "too safe" in other situations, but best we can do for a conservative automatic mode. Seems to work pretty well. So now I have something to wish for. It looks that the most compatible _and_ safe behaviour is to map RAM to X=TEST, which was exactly your first suggestion :) Is this tha same as NOEMS with respect to UMB? I got a little confused with these options and I have MS-DOS help open right now and it is not 100% interpretation proof... I usualy use these options: nothing - No UMB available, smaller lower memory, only for problematic cases NOEMS - I don't use EMS and UMB is enabled. Basic use, could be UMBPCI but this is hardware dependent. VCPI is only needed because it of EMM386 itself. RAM - EMS and UMB available NOEMS RAM - Maybe here the RAM option should not be used (not needed), correct? Please correct me, thanks, Alain --- 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] EMM386 options, was: Idea about Virtual PC compatibility / A20 handling
Michael Devore escreveu: So now I have something to wish for. It looks that the most compatible _and_ safe behaviour is to map RAM to X=TEST, which was exactly your first suggestion :) Safest, but very incompatible with MS expected RAM behavior. Not the reverse either, just something quite different. I don't expect users would want RAM == X=TEST. Ok. If you say so, I agree. And even more because of what is below ;-) nothing - No UMB available, smaller lower memory, only for problematic cases Nothing is the same as RAM with FreeDOS EMM386. UMB's are available and auto-scanned for ROM signatures in range C000-EFFF. EMS is present, I forget the formula for how much but could look it up. Probably defaults to 32M, or successively halving that until sufficient memory exists. I like this. Does MSDOS have UMB in this case? I allways understood that it didn't... In any case, NOEMS - I don't use EMS and UMB is enabled. Basic use, could be UMBPCI but this is hardware dependent. VCPI is only needed because it of EMM386 itself. NOEMS leaves support for a few EMS calls on with MS-DOS, which is stupid, but could be for easier VCPI support. FreeDOS EMM386 also supports these EMS calls under NOEMS because several programs have come to depend on this MS-DOS stupidity. Then there's the EMM device driver renaming, but don't get me started... VCPI pool allocation is made with NOEMS up to 12M automatically, based on 1/4th of available memory. I think. Documented in EMM386C.C and EMM386.ASM source. Just to put the point over the "i"s (just a badly translated saying): In this case UMB is available? I understand that the answer is yes, but it is not clearly stated in the above paragraph. Even it the implementation is stupid, IMHO the inportant fact of this option is liberating 64k on UMB :) RAM - EMS and UMB available Default option with FreeDOS, no difference if it's there or not. OK. NOEMS RAM - Maybe here the RAM option should not be used (not needed), correct? Same as NOEMS, above. Ok, --- One more question: How do I turn off UMB? This is what I understood so far (please correct me if in error) With both UMB and EMS: nothing (this needed RAM in MSDOS) With UMB but not EMS: NOEMS No UMB but with EMS:??? (this was nothing in MSDOS) Neither UMB nor EMS:don't load EMM386 There is still a "???" :( May I suggest a table similar to this in the docs or even help? thanks for everything so far, Alain --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 options, was: Idea about Virtual PC compatibility / A20 handling
Michael Devore escreveu: At 04:23 AM 8/30/2004 +0400, Arkady V.Belousov wrote: 6.22: without RAM no UMB. Though, I think, making UMB even without RAM is acceptable and even more convenient (EMM386 _usually_ used for UMB, so "NOUMB" for disabling UMB is more logical, than "RAM" to enable them). NOUMB option is a good idea for a post 1.0 FreeDOS change. It certainly is a more intuitive option to change the FreeDOS UMB-on default condition. I agree that it is a goog option, but what about compatibility? Alain --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Zurenava DOS extender
Hi Mechael, I agree with what you say below, but... why recomend dos4gw and not Causeway. - I understand that you would be much more familiar with it, and - dos4gw is not free ?? Alain Michael Devore escreveu: At 04:40 PM 9/4/2004 +0300, Luchezar Georgiev wrote: OK, ZRDX 0.47 is buggy. But why both KAVDOS32 (ZRDX 0.49) and QV (ZRDX 0.50) hang up here before showing the prompt on exit in FreeDOS but not in MS-DOS, No, I think ZRDX is buggy, period. And I'll tell you why. But first, --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Zurenava DOS extender
Hi Michael, I have a MS-DOS 6.22 100% guaranteed to be good. It is not complete in terms of orininal MS-DOS garbadge end installer, but it is bootable and installable and have a _complete_ set of usefull utilities (including help). it is 1.4Mb, I can send it to you, just say to what address :) Alain --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Zurenava DOS extender
Hi Johnson, - I understand that you would be much more familiar with it, and - dos4gw is not free I remember it's free of use and distribute. Did you know that the author of Causeway IS Michael Devore? It was a comercial product, now it is free, and it is recomended by OpenWatcom C compiler :) Alain --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Zurenava DOS extender - and others
I am using now WDOX which is fine, is LGPL (100%free) and is the only one that works on my machine Num. 2 (Dell 4100, 950MHz, MS-DOS 7.10) I tested dos4gw and Causeway. The problem is (Maybe Michael Devore cna holp on this :)) I have a TSR that access a Packet driver with basic IP functionality, this TSR can optionaly buffer packets in XMS. The problem is that when I call the TSR (32bit OpenWatcom 1.3 or WatcomC 11) and it accesses XMS the machines hangs or resets or gives a GPF. Here it only happens on this machine, but it happend in clients machines too. If I use WDOSX it works ok... ??? Johnson Lam escreveu: I agree with what you say below, but... why recomend dos4gw and not Causeway. My comment was motivated because Michael is the author of Causeway... - I understand that you would be much more familiar with it, and - dos4gw is not free I remember it's free of use and distribute. the "w" stands for "Watcom version" My licence explicitely ways that it is royalty-free for owners of WatcomC and it is limited to 32Mb. The full version is called WDOS/X and was US$150.00 last time I checked. Alain --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Zurenava DOS extender - and others
Michael Devore escreveu: I have a TSR that access a Packet driver with basic IP functionality, this TSR can optionaly buffer packets in XMS. The problem is that when I call the TSR (32bit OpenWatcom 1.3 or WatcomC 11) and it accesses XMS the machines hangs or resets or gives a GPF. Here it only happens on this machine, but it happend in clients machines too. If I use WDOSX it works ok... I'd have to see a problem setup to do any testing. Could be a DMA problem, could be a bug that doesn't hit an extender's critical area, could be something not's locking code it should, could be a marginal XMS call that fails, depending. Could be a naked mole rat infestation, but probably isn't. We will need to setup a small setup to test it, but it does not happen on all machines and only with VIA NICs, I will try as many as possible machines :( - Andreas will be here only in January, so we can wait... Alain PS. Cont bet on rats. Serious... --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] CHKDSK / DEFRAG / XCOPY to the rescue...
Hi Eric, Eric Auer escreveu: [...] - add a recovery mode to XCOPY which tries to copy all files, does [...] - CHKDSK surface scan should try reading sectors N times. If that fails, mark the sector as broken and try copying the data elsewhere, [...] > - DEFRAG (or CHKDSK) should have a mode 'move data around to make clusters > A ... B empty', optionally marking the whole cluster range as bad after > that. FWIK this is what scandisk does, am I wrong? Doesn dosfsck lates release by yourself do that? - IF XCOPY would not ask about retrying all the time have a look at XXCOPY. (if you don find it I should have a copy) but it is shareware... - IF DEFRAG or SCANDISK would allow me to free and mark-as-broken sectors in the neighbourhood of the actually broken sectors I did that for floppie a long time ago, but I doubt that it would wor today because of simulated geometry. I believe that SPINRITE is the tool for that... a lot. So let us do better than MS - let us introduce configurable XCOPY critical error handling (and error messages which tell you WHICH files are the victims of read/write errors) for a start a flag for "continue on errors" (with on screen/file log) would be a big help and configurable SURFACE SCAN 'confidence' (be more pessimistic, but try hard to rescue data; Spinrite did that in in old days (Seagate STR238 could not live without it) Alain --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Re: I quit.
tom ehlert escreveu: seriously - would you use AnyDOS for your everyday work ? I do. For devellopent. But my clints do it 24/7... (machices are up to P4, graphics mode and database) do you think anyone else does ? Not very much ;-) Alain --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Extracting filesystem from freeDOS
Hi Tom, [...] * Port DosEmu from Linux to SUN SOLARIS * boot dos, giving it a lot of memory (for the RAMDISK) * start XMSDSK * start MS LANMANAGER as server, [...] DosEmu provides packet driver, have you been able to instal MS LANMANAGER using it? I spent a lot of time last month trying to instal MS-CLIENT over a packet driver and was unable to find a driver (shim?) for that. If you can do it, please point me at the right direction thanks, Alain --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] NDIS + ODI + PKT
Does anyone have a copy of PDETHER version 1.05? (pde105.zip) all links I could find in Google are broken... tom ehlert escreveu: Hello Alain, [...] * Port DosEmu from Linux to SUN SOLARIS * boot dos, giving it a lot of memory (for the RAMDISK) * start XMSDSK * start MS LANMANAGER as server, [...] DosEmu provides packet driver, have you been able to instal MS LANMANAGER using it? No. I spent a lot of time last month trying to instal MS-CLIENT over a packet driver and was unable to find a driver (shim?) for that. If you can do it, please point me at the right direction searching for 'ndis over odi' brings on top optics.ph.unimelb.edu.au/help/samba/wfw_slip.htm 'there is no NDIS over ODI skim. however, there's an ODI over PD and an NDIS over ODI shim' tom --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] [OT] A Sync program
Hi Aitor, I use this: Vice-Versa http://www.tgrmn.com/ it is not free (US$80 2 cpus) it has bugs, but it is very good. In the near future I will try this: Unison http://www.cis.upenn.edu/~bcpierce/unison it is free, good, Win/Linux, ssh, rsync, has extensive configurations, etc.. Bothe have databases, but use it diferently. The database is a very important feature: without it, you cannot, as an example move or delete a file and have it replicated in the other machine. Both programs also make copy of everything it deletes. Unison just is harder to configure and I think (not sure) it misses one thing: a side by side view of averything that will be done. This is very important in the Notebook/desktop scenario. Alain Aitor Santamaría Merino escreveu: Hi there, Sorry for the OT, does anyone know of a good and free (to download, not necc. open source) Win32 program that can be used to synchronise the contents of a folder A with the contents of a folder B, that is, copies and replaces all the files in B that are newer than files in A or inexistent in A (no need to touch folder B)? Ok, I could use Windows Explorer, but it has two problems: (1) I don't like that it is not recursing directories very nicely (it says it will replace files without confirmation). This problem is more or less ok, because I think in A there aren't files newer than those in B, but (2) Explorer will overwrite ALL files, thus it can be slow. I would prefer it if it would not overwrite files that match in last modification date, e.g. Any suggestions wellcome, specially if they are prompt (I'd love to do this sync before this weekend). Cheers to all, Aitor --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] 32bit debuggger
Srry if I a little OT, but this list have people that should know: Can I compile and debug with DJGPP in 32 bits? Both in Real-DOS, Win98-dos-box and Dosemu? Andreas needs to develop a new c++ 32 bit project but he didn find any 32 bit compiler that can be debugged in a Windows DOS-BOX :(( thank for any help, Alain Jim Hall escreveu: Thanks Eduardo! I've mirrored this release on ibiblio, and posted a news item on FreeDOS.org. Also, I've added your LSM to the Software List. -jh Eduardo Casino wrote: Hi all, at long last, this is the first version of FreeDOS NLSFUNC. Although it is a complete implementation, it should be considered in alpha stage. The code, as all mine, is ugly and probably buggy, but I wanted to release it for your testing pleasure. You can download it from http://perso.wanadoo.es/samelborp/nlsfunc There is also an HTML help file at that location, just in case somebody is maintaining the HTML help system now that Rob has resigned. NOTES: It needs the UNSTABLE kernel with the patch I've just sent to freedos-kernel. It is FreeDOS-specific, so do not try to run it with MS- DOS or any other DOS flavour. Regards, --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 bugs update
Hi Michael, you keep impressimg me :)) Thanks, very much Alain Michael Devore escreveu: Uploaded to ftp://ftp.devoresoftware.com/downloads are the files emmx13b.zip, EMM386 mostly executable package, and emms13b.zip, EMM386 mostly source package. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: EMM386 bugs update
Hi Michael, thanks for the new naming system. I aprove, I like it. After all this is FreeDOS and it happens to be 8.3 ;-) I often work in plain DOS, ant it is in fact annoying to have the strange ~ names. As for the date stamps, thei get lost when saving the download. Just to let you know that *someone* is happy :)) Alain Michael Devore escreveu: At 11:27 AM 12/8/2004 +0100, Eric Auer wrote: > Uploaded to ftp://ftp.devoresoftware.com/downloads are the files > emmx13b.zip, EMM386 mostly executable package, and emms13b.zip, EMM386 > mostly source package. > These versions follow the latest EMM386 fileset template directory and > naming conventions. Thanks for the template directory part, but I think trying to keep the URL in 8.3 naming convention will only have the result that people who look for emm386 will no longer imagine that emmx could be what they want. You could upload as emm386x-13b.zip and people can save the downloaded file to emm386x.zip, then everybody should be happy. This is an excellent example of why I originally wanted nothing to do with the administrative side of EMM386 and HIMEM. After three iterations of changing directories and names, few people appear any the happier about it than they were originally. With non-8.3 naming convention, downloaders using native DOS applications to grab the files need directions with the atrocious beginning "The file will either immediately rename prompt or download into a weird ~ extended name but you can rename it into a better one afterwards". Even forced renames after non-DOS OS download is an avoidable annoyance. I will here venture a plain personal opinion on non-8.3. filenames for DOS-only downloads: they are stupid. Automatically requiring a rename of any download to be compatible with the operating system the files are explicitly written for is stupid. Bottom line fact is that DOS is an 8.3 named operating system, and LFN's aren't natively supported. No one else that I looked at for FreeDOS base or utility files uses non-8.3 filenames. Get around 75% compliance on date-embedded non-8.3 filenames and then we can talk. Personally, I think looking at the datestamp is sufficient (what else is it for?) and a single emm386.zip file should work, especially if older version files are aged out to archival branching directories or simply renamed, but nobody else liked that idea. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Recommended C Compiler
Hi, I have read four replys to this message, an here goes mine. I still use BC 3.1 when targer is only 16 bits, such as TSRs. It is the best in one thing: it has aa good IDE and this makes debugging very much faster. In many cases, I ven develop a new libray in BC31 and it´s test program, after that the library is used in a 32bit target. One detail: DOS (including FreeDOS and DosEmu) is a very good platform for 32 bit aplication using a few megabytes of memory. I tested a lot Pacific C and my opinion is: drop it. I have tested BC 1.0 and TC 2.1 from the museum but they are realy incomplete in a sense that afects development time, but one of them (I don´t remember whitch) has a reasonable IDE and could be used for a school. I managed to get a licence of BC31 from a magazine, but you can without too much effort recomplile whatever you do with OpenWatcom if you have to release it. So I recomend both BC31 and OW1.3 Alain Goh, Yong Kwang escreveu: Hi. I'm planning to do some DOS programming and I'm hoping that my DOS program will run on MS-DOS, Win9x and FreeDOS as well. So I'm looking for recommendation for a C compiler that works best in generating applications for FreeDOS. In addition, may I know if there is a standard/most common C compiler that FreeDOS developers have agreed on using for FreeDOS development? Previously, I've been using DJGPP for MSDOS and has generally been satisfied except for a little grouse that it seems to be relatively incomplete that I've to download separate packages and libraries from different places; the DJGPP package doesn't appear to me as an integrated and complete development platform. Borland C++ has been left out because it generates only 32-bit Windows console and GUI applications, not DOS executables. Hence I'm thinking of switching over to OpenWatcom. I hope someone who have used OpenWatcom compiler before can advise me on whether the switch from DJGPP will be worth it. I've no experience with OpenWatcom or Watcom compiler before, so I would like to know what I can gain (and lose) in switching to OpenWatcom as my main development platform for DOS (MSDOS and FreeDOS). Btw, I'm also open to other compilers as well, like Digital Mars or Pacific C for example. If you do know of another compiler that seems to be better than those stated here, you may wish to highlight them to me as well. Thank you. Goh, Yong-Kwang [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> * Yahoo! Messenger* <http://uk.rd.yahoo.com/mail/tagline_messenger/*http://uk.messenger.yahoo.com> - Communicate instantly..."Ping" your friends today! *Download Messenger Now* <http://uk.rd.yahoo.com/mail/tagline_messenger/*http://uk.messenger.yahoo.com/download/index.html> --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Recommended C Compiler
Arkady V.Belousov escreveu: Earlier, there was recommended Borland C++ 3.1. But it is very outdated (in sense of language), closed source, commercial, non-free and contains bugs, which will never fixed. I remember that you had a list of BC 3.1 bugs, could you send it to us, please? Alain PS if it is too long send it in PVT --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
