Re: [Freedos-kernel] EXT3 support
The basic idea is to start with a fresh install of an Ubuntu LTS server. Then a Script could install all the rest. I am already doing this on a project and it works very well, all scripts are posted on github: https://github.com/alainm/nfas (sorry, it's in portuguese due to local colaborators) On basic script could install DOSEMU with an updated FreeDOS and maybe a few needed packages. I have a set of guidelines that I could translate Another small script could create a DOSEMU instance. The default screen could be a FreeDOS console Remember that dosemu can run a DOS program from de Linux command line ;-) WHAT I DON'T KNOW is the minimum system to run graphics programs in FreeDOS+Dosemu+Linux, I have allways used with X _Would you give it a try_? Just start with a plain Ubuntu 14.04 LTS 32bits (use VirtualBox), it has a dosemu package that works prety well Alain Em 16-08-2015 03:09, Till escreveu: Quoting Alain Mouette : Why not use all that effort to run FreeDOS over Linux? Dosemu works very well... It has already been done in the past, mas it was slackware based and as soon as released had no mantainance, so it went dead. *) you get all the drivers to run on any hardware *) you can run multiple FreeDOS instances, it works very well *) disk sharing works very well *) networking via PacketDriver woks just fine, it may just be a bit confusing to configure and you can have background tasks in Linux for other tasks ans remote access. It would be just fine to make it over Ubuntu LTS, and I am willing to help. PS: I have some legacy system runing in Dosemu and I use that regularly for development This is a brilliant idea that I would love to see come to life. I'm interested in hearing more about this. Till -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] EXT3 support
Why not use all that effort to run FreeDOS over Linux? Dosemu works very well... It has already been done in the past, mas it was slackware based and as soon as released had no mantainance, so it went dead. *) you get all the drivers to run on any hardware *) you can run multiple FreeDOS instances, it works very well *) disk sharing works very well *) networking via PacketDriver woks just fine, it may just be a bit confusing to configure and you can have background tasks in Linux for other tasks ans remote access. It would be just fine to make it over Ubuntu LTS, and I am willing to help. PS: I have some legacy system runing in Dosemu and I use that regularly for development Alain Em 14-08-2015 23:55, Till escreveu: > I am interested in writing a new driver, one that would allow you to > boot and run dos on a EXT3 partition. In your other message you said > that ETX3 was a multithreaded fs. In that case it would be wiser to > first add multithreaded support to the FreeDOS kernel. It will be > hard, but well worth the time I believe. > > PS(Thank you everyone for your quick replies.) > > Till > > Quoting Louis Santillan : > >> Hiren's BootCD has had something called Paragon Mount Everything > 3.0. >> Or are you interested in writing a new driver? >> >> On Fri, Aug 14, 2015 at 1:28 PM, Ralf Quint > wrote: >>> On 8/14/2015 12:38 AM, Daniel G. wrote: >>>> Greetings, >>>> >>>> I was reading the FreeDOS development wish-list and adding ext3 >>>> support to the FreeDOS kernel is on the list. Is anyone working > on >>>> this at this time? >>>> >>> Doubtful. It's more likely just wishful thinking from someone who >>> doesn't know what all might be involved in actually implementing > this... >>> Ralf >>> >>> --- >>> This email has been checked for viruses by Avast antivirus > software. >>> https://www.avast.com/antivirus >>> >>> >>> > -- >>> ___ >>> Freedos-kernel mailing list >>> Freedos-kernel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/freedos-kernel >> > -- >> ___ >> Freedos-kernel mailing list >> Freedos-kernel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freedos-kernel >> > > > > -- > ___ > Freedos-kernel mailing list > Freedos-kernel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-kernel > -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] CRITICAL BUG - crosslinked files - 2039 unusable
Does this mean that it has been fixed? Alain Em 03-05-2011 04:03, dos386 escreveu: >> Good catch and thanks for the fix! I committed your patch to svn > > Heh ... excellent ... so my excessive HD trashing > http://www.mail-archive.com/freedos-kernel%40lists.sourceforge.net/msg02431.html > 1+1/2 years ago was NOT only waste of time ? > > Thanks to Damien, I'll test 2040 > -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Distribution for REAL USE (was Re: CRITICAL BUG - crosslinked files - 2039 unusable)
I made a very simple distribution, close to the original MS-DOS disks.
Main carachteristics:
- Single floppy
- Single language
- No fancy program or interface at all, but complete functionality
- Simple batch menu, with most functions are for partitioning, formating
and installing.
- Config optional with a supplied Congif+Autoexec containing a simple
but advanced setup.
I was making a new version, allong with required files for GPL
distribution, including a very good windows floppy generation executable
(I create it with a licenced program).
I just put it on wait for the new kernel. So far I found 2 BIG
advantages in the new kernel:
- Better SATA operation, at least in one machine only the new kernel worked
- better security: I use a database program and the new kernel rarely
has lost clusters after system crashes
I am glad to know that there is work on the new kernel's bug :)
Alain
Pat Villani escreveu:
> Hello Alain,
>
> I probably missed it. What is different about your distribution? f it
> is a major imrpvement to what we have, why not distribute it as a
> FreeDOS distribution?
>
> Pat
>
>
> On Thu, Jan 7, 2010 at 7:54 AM, Alain Mouette <mailto:ala...@pobox.com>> wrote:
>
> Hi all,
>
> first of all, Happy ne year :)
>
> Is there anyone working on, o willing to work on this cross-linked files
> bug? It seams to me that this can be very important for FreeDOS use, I
> allways assume that if a bug exists somewhere hidden, it could also
> atack under other circumstances, ie. not only on a 4Gb 99.9% full
> disk :(
>
> I have prepeared a new FreeDOS distribution for REAL USE in the field
> and this is holding me back. I never had problems with disks (older
> kernel), maybe even lass then with MS-DOS 7.10, and the latest kernel
> that I tested is even better (near to no lost cluster on reset). So this
> new version is very exciting :)
>
> Thanks for all,
> Alain
>
> Eric Auer escreveu:
> > Hi dos386 :-)
> >
> >> 1. No new details to the "Crosslink-BUG" ... cluster size is 4
> KiB :-|
> >
> > However, it is very interesting that it involves broken high 16 bits
> > on FAT32 on almost full disks. I hope this helped Bart to zoom in on
> > potential causes for the bug :-).
> >
> > http://sourceforge.net/support/tracker.php?aid=2901916
> >
> www.mail-archive.com/freedos-kernel%40lists.sourceforge.net/msg02431.html
>
> <http://www.mail-archive.com/freedos-kernel%40lists.sourceforge.net/msg02431.html>
> >
> > To summarize your 19 Dec 2009 mail: Use kernel 2039 on a FAT32
> (FAT28)
> > disk, for example 6 GB with 4 kB/cluster and quite full, for example
> > 95 p/c, with fragmented free space. Copy some files, delete some,
> copy
> > some more files. Then, you say, many cross-links show up, mostly
> in the
> > freshly copied two sets of files, also lost cluster chains. You
> are very
> > right that the INTERESTING thing is that the broken files all
> have bad
> > starting cluster numbers, all below 0x1, even though there
> were no
> > free clusters in the first 65536 clusters before the experiment!
> >
> >
> >
> >> 2. Discovered a NEW BUG:
> >
> > Half of it is not a bug, the other half is...
> >
> >> 1. Get WDE or similar
> >> 2. Overwrite both entries in FS-info sector with $'
> >> 3. Reboot to FreeDOS
> >> 4. DIR - there is a massive delay at the end
> >
> > This is because DIR tells you how much space is used / free.
> > For that, DOS has to count all used / free FAT clusters by
> > reading the whole FAT, which is big in FAT32. The FS-Info
> > sector caches the information, but by setting the values to
> > the which you mention, you force a recalculation...
> >
> >> 5. DIR - no delay anymore
> >
> > See above :-)
> >
> >> 6. Try to brew a file or SUBDIR ("MD")
> >> - expected result: should work
> >> - effective result: DOESN'T WORK
> >
> > Do you also get problems with file creation or growth, as
> > far as those involve allocation of more clusters? If yes,
> > which problems, just failure? Or creation of cross links?
> >
> >> 7. Retry and it will work now
> >
> > Interesting!
> >
> >>
Re: [Freedos-kernel] CRITICAL BUG - crosslinked files - 2039 unusable
Hi all,
first of all, Happy ne year :)
Is there anyone working on, o willing to work on this cross-linked files
bug? It seams to me that this can be very important for FreeDOS use, I
allways assume that if a bug exists somewhere hidden, it could also
atack under other circumstances, ie. not only on a 4Gb 99.9% full disk :(
I have prepeared a new FreeDOS distribution for REAL USE in the field
and this is holding me back. I never had problems with disks (older
kernel), maybe even lass then with MS-DOS 7.10, and the latest kernel
that I tested is even better (near to no lost cluster on reset). So this
new version is very exciting :)
Thanks for all,
Alain
Eric Auer escreveu:
> Hi dos386 :-)
>
>> 1. No new details to the "Crosslink-BUG" ... cluster size is 4 KiB :-|
>
> However, it is very interesting that it involves broken high 16 bits
> on FAT32 on almost full disks. I hope this helped Bart to zoom in on
> potential causes for the bug :-).
>
> http://sourceforge.net/support/tracker.php?aid=2901916
> www.mail-archive.com/freedos-kernel%40lists.sourceforge.net/msg02431.html
>
> To summarize your 19 Dec 2009 mail: Use kernel 2039 on a FAT32 (FAT28)
> disk, for example 6 GB with 4 kB/cluster and quite full, for example
> 95 p/c, with fragmented free space. Copy some files, delete some, copy
> some more files. Then, you say, many cross-links show up, mostly in the
> freshly copied two sets of files, also lost cluster chains. You are very
> right that the INTERESTING thing is that the broken files all have bad
> starting cluster numbers, all below 0x1, even though there were no
> free clusters in the first 65536 clusters before the experiment!
>
>
>
>> 2. Discovered a NEW BUG:
>
> Half of it is not a bug, the other half is...
>
>> 1. Get WDE or similar
>> 2. Overwrite both entries in FS-info sector with $'
>> 3. Reboot to FreeDOS
>> 4. DIR - there is a massive delay at the end
>
> This is because DIR tells you how much space is used / free.
> For that, DOS has to count all used / free FAT clusters by
> reading the whole FAT, which is big in FAT32. The FS-Info
> sector caches the information, but by setting the values to
> the which you mention, you force a recalculation...
>
>> 5. DIR - no delay anymore
>
> See above :-)
>
>> 6. Try to brew a file or SUBDIR ("MD")
>> - expected result: should work
>> - effective result: DOESN'T WORK
>
> Do you also get problems with file creation or growth, as
> far as those involve allocation of more clusters? If yes,
> which problems, just failure? Or creation of cross links?
>
>> 7. Retry and it will work now
>
> Interesting!
>
>> EDR-DOS doesn't have this bug.
>
> It probably also has the delay? I assume by bug you only mean
> the problem of creating a directory after invalidating FS-Info?
>
> Eric
>
> PS: I think 2039 got less publicity than 2038 and 2038
> has more conservative updates. Combined, this means in
> 2039 you have more changes but (yet) fewer testers...
>
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] CRITICAL BUG - crosslinked files - 2039 unusable
Hi, I came across a bug in the new kernel that might be related: If I copy a file from disk ro a floppy *using NDN * the copy is ok and any further operations with NDN crashes. If I use the copy command everything is ok. This is probably memory related, but does not happen with older kernel. This is important to me, so, please orient me to whatever test may help and I wil do it asap... :) Alain Bart Oldeman escreveu: > Hi, > > I'm having a look. But I can't reproduce it so far. So: > * how large is your FAT partition exactly? There is always the GB/GiB > confusion... > * what is the cluster size (I'm looking for potential overflows) > * does it happen with plain FreeCOM COPY, XCOPY, or any copy? > > Bart > -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] suggestion - put kernel svn revision version number in sys config data
Christian Masloch escreveu: >> Alain mentioned that it is hard to keep an overview which >> kernel file is which version, for example if you want to >> report a problem or want to compare kernels. For that it >> would be a great help to put for example the SVN release >> number in there. SYS CONFIG can then be used to show it >> for any kernel file without having to boot with the file. > > Any chance there will be a (21.33FF style) call to retrieve that number > from the running kernel too? You can't be sure that the kernel file on C: > or A: or wherever is the one actually running. (Assuming a standard > system, the file still could have been updated to another kernel revision.) Suggestion: it could be added to the Kernel Id string, like "SVN:1500". Today it has prety useless information, mine just says "FreeDOS Kernel version 0.0.35" (re-translation) which is not to be cross referenced with anything. It would be nice to have that string as plain text in the binary too!! Alain -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 2039-svn build
Aitor Santamaría escreveu: > > Time ago, and if I remember correctly, Arkady built a simple OW pack > having the basic OW for DOS, and being small enough, but probably this > is discontinued with the newer versions of OW, right? It is not a matter of being discontinued. What he did was just simple: 1) install using the windows installer 2) remove all the files not needed for DOS, which is quite a lot 3) repack in .zip format just to be easy for using in DOS. the hard part is only (2) and the files should be the same as with the old verion. Alain -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] ASUS problem
Hi all, I use regularly FreeDOS in users instalations with brand new, superfast motherboards. The aplication is heavy Database usage and FreeDOS is prerforming better then MS-DOS... There is a systematic problem only with ASUS motherboards (in the last 3 years aprox.) System crashes, files get corrupted, etc :( :( Does anyone have any information or Idea about this problem? Would any of Jack's driver help? Thanks for any info, Alain -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
Hi Christian, I think that you are not being polite. You are new here and you start by wanting to change everything. Why don't you start by fixing a few bugs? Alain Christian Masloch escreveu: >>> Which app crashes from running on a FAT+ kernel? (Presuming you don't >>> even >>> have that large files, or that the app doesn't access these files.) >>> Excluding low-level disk utilities such as defragmenting or disk >>> checking >>> programs of course, because EVERY new or extended filesystem breaks >>> them. >> each and every general file handling program like: >> COPY, XCOPY, Norton/Volkow Commander, ... >> ZIP, RAR, ... >> CHKDSK (and don't tell me CHKDSK isn't important), all Norton stuff >> xxBACKUP >> >> while they probably won't crash, some wont to what they >> are expected to do. >> >> Are you prepared to check the entire ecosystem of DOS utilities if >> they can handle 4GB+ size files ? >> >> it's probably MUCH a better idea to teach this hypotetical blueray >> player to handle multiple files. >> >> that's the reason I think that 4GB+ is a real stupid idea. > > >>> (Presuming you don't even >>> have that large files, or that the app doesn't access these files.) > > I don't think copy or archive utilities would care if they won't access > the large files. > >>> Excluding low-level disk utilities such as defragmenting or disk >>> checking >>> programs of course, because EVERY new or extended filesystem breaks >>> them. > > I would describe CHKDSK as "defragmenting or disk checking program". I > mean, did you even READ my mail? It's not like you have to, but please do > if you're going to answer it. > > >>> DOS-C's FAT+ support could be set by default >> I don't care what you do to DOS-C. but the FreeDOS kernel shouldn't >> support FAT+ > > Yo, as mentioned in the previous mails, I refer to the FreeDOS kernel as > DOS-C. And maybe you're right, and the FreeDOS kernel needs forking for > every feature. > >>> Since DOS-C doesn't (yet) support FAT16 file systems larger than 4 GiB >> yes another stupid idea. >> >>> , FAT16+ is no option anyway. >> right. > > Sometimes I think your mails aren't worth an answer. > > -- > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > ___ > Freedos-kernel mailing list > Freedos-kernel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-kernel > > -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] New devellopment
Hi Jeremy and Pat, I am very glad to have you both back actively in the FreeDOS comunity. I just wanted to express my peronal opinion. FreeDOS is very important to me, I activelely use it in users instalation. (www.cosmodata.com.br) Appart from FreeDOS being free is has a big advantage: it works better: I have much fewer database problems with FreeDOS then with MS-DOS 7.10... I believe that there is too much enthususam about new features for FreeDOS. I believe that what what has happened in the last month is just what is more important: bugfix and cleanup. There are a lot of small problems in FreeDOS, with that FreeDOS will be just the best "DOS". And FreeDOS has the advantage of working very well on almost all new machines. The only exception is ASUS which a constant source of problems. Thanks, Alain -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
Eric Auer escreveu: > > The problem is that there were almost no changes in UNSTABLE in > the last 3 years, so it will need "undusting" before it can be > useful for new experiments. I suggest to put the main focus on > careful, non-experimental bugfixes for trunk for the moment. Yes, I agree with that. I personaly have two annoying bugs that I will make test programs for: 1) floppy change while a program is running should be possible with dos-disk-reset 2) Subst is not really functional. I deppend on it to remove once and for all the old MS-DOS from my machine... I will have some time this month, and I am very excited with all this renewed kernel activity. I will maeke test cases for bothe bugs. Alain -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Fwd: Re: state of kernel 2038
Kenneth J. Davis escreveu: > I am still reviewing and testing the pending patches... but progressing. :-) I am very very glad of rearing this. I use FreeDOS for clients, and it is performing better then MS-DOS 7.10... I ma not sure why, but I have fewer database problems with FreeDOS :) I am waiting anxously for the new version 1.1. I was working with Geraldo Neto, but he is very busy at the moment, and I will be back soon :) Alain -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] pkunzip and unzip acting differently with -d command
Travis Siegel escreveu: > > Not exactly. > This error does not occur in msdos or drdos, only freedos, Ergo, > freedos is at fault. > That's why I wanted to know if there was any way to track down the > error, so it could be fixed. Then you are correct... I hope that you can help in fixing it :) In fact, I have an annoying bug very siminar to that, where unzip does not create a directory... Alain -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] pkunzip and unzip acting differently with -d command
From your description, it looks like there is a bug in pkzip. That is a comercial product, so the answer is simple: BUY one and ask for support... As to unzip, it is freeware, well supported, and in fact it is a port of the Linux program. That is why it behaves more in a "unix way", and has fewer bugs. Alain PS: btw, we do neither use nor support ilegal programs in this list ;) Travis Siegel escreveu: > I'm not sure if this is the right place for it, but I've noticed > recently, that pkunzip and unzip treat files with directory > information differently on freedos. > I'm using the 1.0 kernel releases (tried upgrading to 1.1, but had > some issues, so had to reinstall 1.0) > But, what happens is this: > When extracting a zip file that contains subdirectories, and using the > -d command to recreate these directories: > pkzip gives me an error each and every time it runs across a > subdirectory, stating that it can't create it. (it does though, so > not sure what's causing the error) > However, unzip does not report anything, and happily creates the > subdirectories w/no problems. > I'm curious how one would go about tracking down this problem, would > the debugging kernel mentioned here help, or is there some other way > to track these kinds of problems? > It seems to be *every* zip file, but up to now, I've only been working > with pre-existing zip files, I've not tried creating my own to see > what happens. > I'm using pkzip 2.50 for dos. > > > -- > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > ___ > Freedos-kernel mailing list > Freedos-kernel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-kernel > > -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Big disk - 500Gb
Hi Aitor, many people have reported that FAT is slow for very big partitions and that NTFS is better for that. I regularly use FAT32 for Data partitions of around 5Gb and is quite fine, using it in Linux or XP that have a good cache. On my notebook I have XP instaled also in a FAT partition because of mantainance. It works reasonably well, but the truth is that I use XP only eventualy :) > One question, did you happen to manage how does WinNT perform with > such an "enlarged" FAT system? I supose that this is probably plain incompatible. There are allways limits in old things simply because 500Gb was just unthinkable at the time. Cheers, Alain >> >> I just tested the FreeDOS format on the big disk. IT WORKS FLAWLESSLY :) >> >> the previous problem was due to a too old kernel. I used the one from >> Rugxulo labeled as fat-security. >> >> - Fdisk did everything as expected >> SATA2 500Gb disk one 100% partition >> - Format did everything as expected both in quick mode of surfece scan >> Warning: Each FAT is 119208 sectors, > 16MB-64k, Win9x incompatible >> FreeDOS goes well beyond old MS-DOS limits >> - Disk booted normaly >> - Machine is an Athlon X2 4400+ dual core, with 2Gb RAM. I may be that >> this insane amount of memory (matches the insane size of the disk) >> helped to avoid the reported "too big disk" message. >> - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Big disk - 500Gb
Hi all, I just tested the FreeDOS format on the big disk. IT WORKS FLAWLESSLY :) the previous problem was due to a too old kernel. I used the one from Rugxulo labeled as fat-security. - Fdisk did everything as expected SATA2 500Gb disk one 100% partition - Format did everything as expected both in quick mode of surfece scan Warning: Each FAT is 119208 sectors, > 16MB-64k, Win9x incompatible FreeDOS goes well beyond old MS-DOS limits - Disk booted normaly - Machine is an Athlon X2 4400+ dual core, with 2Gb RAM. I may be that this insane amount of memory (matches the insane size of the disk) helped to avoid the reported "too big disk" message. See more below... >> 1) new disk was used with Linux, but a first primary partition was made >> but never formated > > Make sure it is flagged as fat32 and as lba. Check possible > messages from initdisk early during freedos boot as well. > > I recently tried making a DOS bootable partition on a new > disk, too, and found: 1. I had to mimick a "fdisk /mbr" > to make anything boot 2. I had to say my partition is LBA > and bootable. 3. I had to tell sys-freedos-linux that the > disk and offset are 255 (auto) and 63 (see fdisk -u -l in > Linux) respectively as mkdosfs had failed to set those. I > also told sys-freedos-linux to use LBA style boot sectors > to avoid any geometry troubles but that was optional :-). I did all the tests in FreeDOS, nothing else ... Normal use is with GRUB which can handle all that without problem >> 2) booted FreeDOS 1.0, and with fdisk deleted everything and creared >> only one primary partition for the whole disk > Why did you delete the partition and make a new one again? > Same bugfix suggestions as for step 1. I had used that same disk for other tests, including Ubuntu... >> 3) rebooted >> 4) fdisk /mbr (to remove grub) >> 5) format c: /s /u > > Try without /s. Use the /d option to get debugging messages. > Use the combination /q /u unless you insist on waiting for > days until format completes. Really. So: FORMAT C: /Q /U /D both /Q and /U worked as expected with new kernel :) Thanks to all, Alain - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Big disk - 500Gb
Hi, I just tested fdisk and format on a 500Gb disk 1) new disk was used with Linux, but a first primary partition was made but never formated 2) booted FreeDOS 1.0, and with fdisk deleted everything and creared only one primary partition for the whole disk 3) rebooted 4) fdisk /mbr (to remove grub) 5) format c: /s /u I get this message: FATAL: Cliuster size is not 0.5, 1, 2, 4, 8, 8, 16, 32, or 64k but 0.0k. [Error 58] can someone figure this out? I im doing this for the sole purpose of testing FreeDOS, and I have a few more days before I do some better use of that disk Alain - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Two problems and patches related to Floppy Disk
Eric Auer escreveu: > >> Problem 1: Maxell new FD has No 55-aa magic number in boot sector. > > You might have fixed that the wrong way round... FreeDOS tries too > much to behave well for unformatted disks, which should be fixed in > www.coli.uni-saarland.de/~eric/travis.zip ... the idea is to make > clear that disks are not in standard format instead of trying to > treat them as if they were. The QUESTION is whether all your disk > tools enjoy the patch :-). The GOOD thing is that things should be > safer the "Travis" way. The BAD thing is that you will probably > have to (quick-) format your Maxell disks once before the Travis > style kernel lets you access them. Please try :-). I am not so sure if it is the wrong way. Most of my floppy problems may be related because Maxell is the most common brand here. Let's think a bit... Maxell floppies work just fine with MS-DOS and DR-DOS, which I used a lot. So they *have to* work well inFreeDOS too, because users buy them and expect them to work (yes I know they *should* format them but I repeat it endlessly withou result) Maybe, if you feel unsafe about using a floppy without he 55AA mark, some other test could be done to decide that the floppy is ok :) Please consider this... >> Problem 2: Floppy disk change recognition problem. > > Implementing int 13 hooking can be quite complex, how long is > your patch and did you check it and have it reviewed? Our own > UNSTABLE kernel branch for example had int 13 hooking as work > in progress but I think it was not smooth yet. You can find > the source of this branch in our SVN repository :-). Maybe (I haven't checked) a simple hook of int13, just for disk cahnge can be made safely, while a more complete solution is under way. The unstable branch will take a very long time to come, and we need to fix this floppy problem because it causes Data Corruption :( Alain >> Problem 1: Maxell new FD has No 55-aa magic number in boot sector. >> When we used Maxell FD, we encountered strange phenomena. We wrote files to >> FD. >> Write process was looking good. But there is no file in checking the FD on >> Windows... getbpb... if non 55aa then FreeDOS assumes 720k (??)... >> ROM-DOS, PC-DOS and Windows has no problem with the Maxell FD. So I think >> FreeDOS is too strict in checking boot sector format. Original FreeDOS >> checks 55-aa magic number and sector size (=512). My patch disables >> checking of 55-aa magic number and only checks sector size... >> fdos-maxell-fd-patch-080818.diff modifies kernel/dsk.c. > > > >> Problem 2: Floppy disk change recognition problem. >> When we write two FD on our application, the first FD's directory >> entries was copied onto the second FD. This problem was not occurred >> on ROM-DOS and PC-DOS. After precise investigation, I found that our >> application is calling BIOS int-13h AH=02h(Sector read) before the >> second FD write. > > Ouch. > >> Test program DISKCHG.C demonstrates this problem through steps as follows. >> 1. insert disk-1 >> 2. write A:FILE1 calling DOS >> 3. change FD to disk-2 >> 4. read FD boot sector calling BIOS int-13h AH=02h > > Probably to verify that disks were changed, but in FreeDOS > with the side effect that DOS itself misses the change... > >> 5. write A:FILE2 calling DOS >> Disk-2 directory entry contains two files FILE1 and FILE2. >> >> Normally disk change is notified on calling BIOS int-13h AH=00h-05h,08h, >> 15h-18h. But disk change notification from BIOS is the ONLY ONCE. > > Exactly... > >> So on the subsequent call of BIOS int-13h AH=16h(Detect disk change) >> from FreeDOS kernel, no disk change will be notified and FD cache in >> kernel will NOT be flushed. Then the first FD's directory data will >> be written into the second FD. >> >> My patch introduced int-13h hooking. Disk change status on calling >> int-13h AH=00h-05h,08h,15h-18h is memorized and reported on the call >> of fl_diskchanged(). > > What motivated your selection 0-5,8,15h-18h? Sounds okay :-) > >> Perfect disk change recognition will be accomplished by the patch. > > Possibly ;-) > >> Though I have not examined other DOSs(PC-DOS, ROM-DOS), >> the same hooking may be used. > > Good idea - avoid touching closed source software while > writing GPLed software to stay on the cleanroom side :-). > > Eric > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Two problems and patches related to Floppy Disk
You are a genius... This floppy change problem has been around for some time because it is hard to reproduce. The steps 1 to 5 in problem 2 are all done from a single running program? If so it may be related to a problem I encontered a few times. Thanks, very much Alain Koike Toshio escreveu: > Hello FreeDOS developers. > > We are using FreeDOS 1.0 in our embedded systems. FreeDOS is a good > replacement of ROM-DOS we previouslly used. Thank you for all the great work > on FreeDOS. > > I found two small problems related to Floppy disk(FD) and fixed it by > modifying FreeDOS kernel sources(2036 cvs). I send patches to fix these > problems. My patches are applicable to kernel 2036 cvs. > If you consider the patches and incorporate to your kernel tree, it should be > great for me. > > The patches are uploaded here. > http://us.f13.yahoofs.com/bc/48b6f314_185bc/bc/freedos/patch080818.zip?bfh__vIBxIiwN9fQ > > Two problems are: > > Problem 1: Maxell new FD has No 55-aa magic number in boot sector. > Problem 2: Floppy disk change recognition problem. > > --- > Problem 1: Maxell new FD has No 55-aa magic number in boot sector. > > When we used Maxell FD, we encountered strange phenomena. We wrote files to > FD. > Write process was looking good. But there is no file in checking the FD on > Windows. > After precise investigation, I found a lack of 55-aa magic number in the last > two bytes of the boot sector of Maxell FD. FreeDOS getbpb() function is > checking 55-aa magic number. If no 55-aa magic number, FreeDOS assumes the FD > as a 720KB(not 1440KB) FD. > Maxell FD boot sector dump (No 55-aa at 01feh) > eb 34 90 4d 41 58 45 4c 4c 20 20 00 02 01 01 00 |.4.MAXELL .| > 0010 02 e0 00 40 0b f0 09 00 12 00 02 00 00 00 00 00 |[EMAIL > PROTECTED]| > 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > TDK FD boot sector dump (There's 55-aa at 01feh) > eb 34 90 49 42 4d 20 20 33 2e 33 00 02 01 01 00 |.4.IBM 3.3.| > 0010 02 e0 00 40 0b f0 09 00 12 00 02 00 00 00 00 00 |[EMAIL > PROTECTED]| > 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 || > 0030 00 00 00 00 01 00 fa 33 c0 8e d0 bc 00 7c 16 07 |...3.|..| >: > 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..U.| > -- > ROM-DOS, PC-DOS and Windows has no problem with the Maxell FD. So I think > FreeDOS is too strict in checking boot sector format. Original FreeDOS > checks 55-aa magic number and sector size (=512). My patch disables checking > of 55-aa magic number and only checks sector size. > > fdos-maxell-fd-patch-080818.diff modifies kernel/dsk.c. > > --- > Problem 2: Floppy disk change recognition problem. > > When we write two FD on our application, the first FD's directory entries was > copied onto the second FD. This problem was not occurred on ROM-DOS and > PC-DOS. > After precise investigation, I found that our application is calling BIOS > int-13h AH=02h(Sector read) before the second FD write. > Test program DISKCHG.C demonstrates this problem through steps as follows. > 1. insert disk-1 > 2. write A:FILE1 calling DOS > 3. change FD to disk-2 > 4. read FD boot sector calling BIOS int-13h AH=02h > 5. write A:FILE2 calling DOS > Disk-2 directory entry contains two files FILE1 and FILE2. > > Normally disk change is notified on calling BIOS int-13h AH=00h-05h,08h, > 15h-18h. But disk change notification from BIOS is the ONLY ONCE. So on the > subsequent call of BIOS int-13h AH=16h(Detect disk change) from FreeDOS > kernel, no disk change will be notified and FD cache in kernel will NOT be > flushed. Then the first FD's directory data will be written into the second > FD. > > My patch introduced int-13h hooking. Disk change status on calling int-13h > AH=00h-05h,08h,15h-18h is memorized and reported on the call of > fl_diskchanged(). > Perfect disk change recognition will be accomplished by the patch. Though I > have not examined other DOSs(PC-DOS, ROM-DOS), the same hooking may be used. > > fdos-fd-change-patch-080818.diff modifies kernel/main.c and > drivers/floppy.asm. > > --- > > Please consider my patches. > > Thanks for your readin
Re: [Freedos-kernel] Suggestion: Int 0x21, AX=0x7305, CX=0xFFFF handler
Tom Ehlert escreveu: > >> I hope you did see the mail earlier this week which says that >> kernel 2038 is almost ready anyway ;-). > > whatever 'ready' means when nobody (except you self) tested it so far. > > in the good old times, we had a couple of prereleases, and also of > post release fixes. That is a good idea, Eric, why not redase a 2038rc1 ??? Alain - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] roadmap for freedos kernel 2038
Johnson Lam escreveu: > > I always have 20, but my point is 20 is for user application, system should > not count in the list, since they are a "must". Buffers are alocated dinamicaly which is a better aproach than reserving some for this and some for that... What I don't understand is why you want to reduce buffers? Alain - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] roadmap for freedos kernel 2038
Johnson Lam escreveu: > Did you mean set the FILES=2 really have 2 buffers? This *should not* happen, DOS opens 5 files by default: stdin, stdout, stderr, auxin and aux out. An extra one is needed with dos extenders. I would say that 7 or 8 would be a minimum to keep things running. By default minimum is 20 buffers, I believe that this would be nescessary for compatibility Alain - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] freedos boot menu line change suggestion
My opinion:
F8 *should* remain, people are just used to it.
gotoxy *shoul*not* exist, that is trouble in some (too many) cases
> Instead of "ENTER for default", one could write "ENTER for [1]"
> where 1 is the default in this example.
I vote "ENTER for default" *but* it shlould be obvious which is the
default, otherwise the other option is better.
Alain
Eric Auer escreveu:
> Hi, what do you think about the following patch:
>
> --- config.c(Revision 1354)
> +++ config.c(SUGGESTED)
> @@ -1918,16 +1918,16 @@
>printf(" (Selection=%d) ", MenuSelected);
>
> if (MenuTimeout >= 0)
> - printf("- %d \b", MenuTimeout);
> + printf(" %d \b", MenuTimeout);
> else
>printf("\b\b\b\b\b");
>
> if (MenuColor != -1)
>printf("\r\n\n ");
> else
> - printf(" -");
> + printf(" ");
>
> -printf(" Singlestepping (F8) is: %s \r", singleStep ? "ON " : "OFF");
> +printf(" Singlestepping (F8) is %s \r", singleStep ? "ON " : "OFF");
>
> key = GetBiosKey(MenuTimeout >= 0 ? 1 : -1);
>
>
> Background: The current menu line with non-full-screen menu is:
>
> Select from Menu [012], or press [ENTER]- 2 - Singlestepping (F8) is: OFF
>
> This is too long - if you have too many menu items, it wraps around.
> My patch simply makes the line minimally shorter:
>
> Select from Menu [012], or press [ENTER] 2 Singlestepping (F8) is OFF
>
> If you hit space, the old version changes to:
>
> Select from Menu [012], or press [ENTER - Singlestepping (F8) is: OFF OFF
>
> This has two errors: The ] is removed and OFF is visible twice.
>
> A good menu line should show the menu choices, hint people about
> the F5 and F8 key (if you ask me, F8 does not need to be a toggle,
> it can also be "hit it at least once to enable single stepping")
> and about the time left until the default choice is selected. It
> could even show which selection is the default one.
>
> It would be good to have better suggestions than my patch above, to
> get a really nice menu line :-).
>
> As far as I remember, the unstable kernel shows an even longer
> menu thing which is 3 lines long (which is not nice if you want
> to read the messages of your BIOS POST) and uses gotoxy (which
> is not so nice if you use a serial console). I think the 3 line
> style has the F5/F8 hint and status at the bottom, choice list
> 2 lines above, timeout line in the line between both lines.
> What I would want is a ONE line menu thing.
>
> Example, the [2] would be the timeout-for-default countdown:
>
> Select from Menu [012], ENTER for default, F8 for singlestepping [2]
>
> If you hit F8 at least one, this could change to:
>
> Select from Menu [012], ENTER for default. Singlestepping is on! [2]
>
> Instead of "ENTER for default", one could write "ENTER for [1]"
> where 1 is the default in this example.
>
> Whatever. Suggestions please :-).
>
> Thanks! Eric
>
>
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> Freedos-kernel mailing list
> Freedos-kernel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel
>
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] More on SUBST...
I have more information on SUBST: Using subst from FD10 and kernek2036 from Eric's site, most things work... What is not working is the C function getcwd() which returns (in this case) M:\CONFIG instes=ad of M:\ Program with problem is OpenWatcom 1.6 in 32 bit. I will be out for 2 days, I will make tests in 16 bits... Alain - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] SUBST is working?
Hi All, is there a trick to use SUBST? is anyone using it? I tryed both subst from 1.0 and sw-swsubst32 from ibiblio. using kernel 2036 from http://www.coli.uni-saarland.de/~eric/stuff/soft/by-others/kernel2036-binary.zip it works better... explaining: with the old kernel, M:> t.bat does not work with 2035 works with 2036 M:> M:\t.bat works allways BUT, programs don't find files. Explaining: if a program tries to open a file, it fails... There was some changes in the "truename" function, this looks like it is related... I would appreciate *any* hint, Alain - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] please change the default freecom and increase the kernel version
Bernd Blaauw escreveu: reason was for better bug reporting. People often only report the FreeDOS version, or something out of VER. Hardly ever VER /R, let alone the production date of a (CVS) kernel which can only be viewed at boottime. I agree. I would like to propose thar the "VER" command shows both versions, the ver and the ver /r to minimyze this. I can even make the patch if there is no-one available. Would averyone agree to include it? Alain --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] please change the default freecom and increase the kernel version
Eric Auer escreveu: Hi, http://fdos.org/kernel/ makes people use 8086 FreeCOM if I understand the text right. This means they will likely have no XMS swap and no LOADHIGH. In short, they will think FreeCOM is really a BAD command.com I agree. My other wish is using a new version number. PLEASE PLEASE PLEASE call the head kernel of [some date in the NEAR future] 2036 and the unstable/devel kernel of [same date] 2037. Yes, yes,yes. I vote for a different version number for each release. Alain --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] FreeDOS big problem - please Help!
Not so long ago I made my first test of FreeDOS in a real *user* machine. It worked very well in a fairly heavy database application wit mostly small aesthetic problems. Exept for one problem that mde me *remove* FreeDOS: when writing diskettes with a backup programs only the first floppy works as expected. From then on, only a small portion is written (to the end of the disk) and it dets very very slow. If I exit the program and start again, the behaviou is reset, that is, firts disk is ok and next disks not. I belive this is a *disc*change*detection* problem because what little is written to the disk is at the end of the fat, in an area corresponding to the free space that existed in the first disk before writing to it. All disk are ok if checked with both scandisk and norton. It was very frustating to remove FreeDOS from a real user after all these years of progress. Please help me... Alain PS. whaen I first reported this, it was summer hollydays and most developers where not reacheable... :(( PS2: Sorry if some receive 2 copies of this, but I am posting it both to the dev and kernel lists --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] UDMA2 testing
I just made some tests with UDMA2 and had some unexpected results: Why is FreeDOS so much slower (60% no UDMA, 14% with UDMA)??? Is this consistent with other experiments? Please, I would like to here comments on this ;-) UDMA 7.0 and UDMA2 2.5 had the same performance. On instalation it says mode 6, speed= 105Mb/s testing with RAWSPEED 2.2 (from older udma versions) writes/reads a 256Mb file to disk (figures in Mb/s) FreeDOS MS-DOS7.10 No UDMA, no cache R=1.4 W=1.4 R=2.3 W=2.8 No UDMA, cache R=1.3 W=1.4 R=2.3 W=2.7 UDMA2, no cache R=6.3 W=4.4 R=54.2 W=16.0 UDMA2, cacheR=5.5 W=4.4 R=39.5 W=15.7 FreeDOS kernel= , lbacache 22sep2004 with tickle, Himem/emm386 v2.01 MSDOS from Win98se, cache=smartdrv, himem/emm386 Machine is AMD Semprom 2.2GHz, PcChips with SiS741GX, Disk is 2Gb partition at the beginning of 40Gb Thanks a lot, Alain PS. sorry for the post to devel+kernel but some people don't read both. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-cvs] kernel/kernel initdisk.c,1.34,1.35
Kenneth J. Davis escreveu: I personally like cvs log and try to commit things in chunks so the log and diff are easy to follow for future references. Do you know of any text or refference about this? I am starting a new big project that will use CVS and I would very much appreciate any information about how to use it better or "get more out of it" Alain PS: I am posting back to the list because I believe that more than one preson here can help with this :) --- 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] announce: kernel 2035a released
Does this fix the DOSLFN problem reported here? http://www.geocities.com/jadoxa/doslfn/index.html - FreeDOS has a problem with extended DPBs, which causes problems with XMSDSK (DOSLFN thinks the RAMdisk is FAT32). It also does not support the Set Extended Error function, which causes problems with Volkov Commander (disk error on blank drives). Here is a FreeDOS patch and kernel (build 2034, NASM 0.98.38, Borland C++ 3.1, TLINK 7.01, 386) to fix them. Jason Hood. 4 December, 2004. - It *is* a bit old, but I asked this before and got no answer at all. Please, does anyone know about it? LFN are important to work under dosemu (I had to do a little gimm just to unzip this new kernel without reverting to Window$) Thanks, Alain Interim FreeDOS Kernel Maintainer escreveu: Kernel 2035a has been tagged and uploaded to sourceforge. This is primarily a bugfix only release, see docs/history.txt for details. There are still some important changes in the dev series that I have not yet merged over (such as the country.sys work, sys, ...) but there have been a few useful bug fixes and I wanted a stable release with them. Jeremy --- 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel --- 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Optimize and OpenWatcom
Hi Bart (are you around?)
Thanks this worked fine (it took some time to test)
Alain
PS: you are getting good at reading minds ;-)
Bart Oldeman escreveu:
On Thu, 6 Jan 2005, Alain wrote:
Peter Fedorow escreveu:
OmmitIfOptimizeSize break ();
Has anyone managed to make this construct qork with OpenWatcom?
We (me and Andreas) have run across this issue for debug macros and the
/##/ construct aparently does not work. We would appreciate any hint to
an alternate construct ;-)
I cannot read your mind to see what you want exactly, but of the
following the first construct works with any C89 compiler; the second,
which saves a pair of brackets is C99-style (works with OW and GCC, not
with old Borland compilers).
#ifdef DEBUG
#define DebugPrintf(x) printf x
#else
#define DebugPrintf(x)
#endif
DebugPrintf(("hello"));
#ifdef DEBUG
#define DebugPrintf2(...) printf(__VA_ARGS__)
#else
#define DebugPrintf2(...)
#endif
DebugPrintf2("hello");
Bart
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Problem with function 68h
Is there a known problem / fix for int21 function 68h ?? I am getting an error return under Dosemu + kernel 2035 in a CodeBase function file4lowFlush() The code is (OpenWatcom 1.3, 386 mode): dosFlush.h.ah = 0x68 ; dosFlush.x.bx = (unsigned int)file->hand ; intdos( &dosFlush, &dosFlush ) ; if ( dosFlush.x.cflag != 0 ) ... From RBIL D-2168--- INT 21 - DOS 3.3+ - "FFLUSH" - COMMIT FILE AH = 68h BX = file handle Return: CF clear if successful all data still in DOS disk buffers is written to disk immediately, and the file's directory entry is updated CF set on error AX = error code (see #01680 at AH=59h/BX=h) SeeAlso: AX=5D01h,AH=6Ah,INT 2F/AX=1107h ----- Alain --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel entry.asm,1.27.2.1,1.27.2.2
Arkady V.Belousov escreveu:
Hi!
4-Янв-2005 19:05 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
Fix divide error message text
+++ entry.asm 4 Jan 2005 19:05:08 - 1.27.2.2
-; print a message 'Interrupt divide by zero'
+; print a message 'Interrupt divide error'
This is not fix, this is change - though "division by zero" interrupt
INT0 hapens not only in case of real division by zero, but this ("Divide by
Zero") is a standard name. On the other side, "Interrupt divide error" I
read as "error in dividing the interrupt", so, if you wish to give more
meaningful name, there should be something like "Interrupt: division error".
I agree :)
Alain
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel entry.asm,1.27.2.1,1.27.2.2
Hi Tom,
Arkady V.Belousov escreveu:
Hi!
4-ÐÐÐ-2005 19:05 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
Fix divide error message text
+++ entry.asm 4 Jan 2005 19:05:08 - 1.27.2.2
-; print a message 'Interrupt divide by zero'
+; print a message 'Interrupt divide error'
This is not fix, this is change - though "division by zero" interrupt
INT0 hapens not only in case of real division by zero, but this ("Divide by
Zero") is a standard name. On the other side, "Interrupt divide error" I
read as "error in dividing the interrupt", so, if you wish to give more
meaningful name, there should be something like "Interrupt: division error".
Alain>>I agree :)
Tom> I disagree :(
I don't understand why, for curiosityÅ sake only: "interrupt divide
error" in english is ambigouous and can be interpreted in two ways.
Anyway, I vote for the exact MS-DOS message for compatibility.
Alain
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Optiize and OpenWatcom
Peter Fedorow escreveu: OmmitIfOptimizeSize break (); Has anyone managed to make this construct qork with OpenWatcom? We (me and Andreas) have run across this issue for debug macros and the /##/ construct aparently does not work. We would appreciate any hint to an alternate construct ;-) Alain --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Lucho gives up arguing with Arkady
Lucho, you introduce change in interface. _Such_ actions necessarily _must_ be discussed and approved. By whom? By the Boss? Who is the Boss? Arkady? Hi Lucho, don't feel hurt, he is just sayint what we yelled at him so many times :) The boss is ... gess who? the comunity, represented in this list... Cheer-up ;-) Alain --- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/boot oemboot.asm,NONE,1.1.2.1
Arkady V.Belousov escreveu: Hi! 7-Сен-2004 19:17 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: KD> Update of /cvsroot/freedos/kernel/boot KD> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv28417/boot Third (or 5th?) times of asking (without answer): where and how download latest (unstable) kernel sources? And, as I understand, there is now 4 alternate trees: 2035, 2035-tom, 2035-Lucho and 2035-Jeremy? To me this is good news. I was thinking that _I_ was the only one confused about this ;-) Alain PS I am particularly interested in "2035-tom" which I understand is "rock-solid" and has the 32rtm bug fixed. --- 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel no longer removes or renames the current directory
Hi Luco, I did some changes to the biggest file of all, FATFS.C. Now the kernel no longer removes or renames the current directory of the drive for which this is requested. This says that it does not do what is requested... Could you please rewrite or explain it? 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Information wants to be free
Good helth, bee well, etc.. :) Alain Arkady V.Belousov escreveu: Hi! 22-Авг-2004 22:39 [EMAIL PROTECTED] (Alain) wrote to [EMAIL PROTECTED]: PS: Currently I improve (cure) my nose, so I again delay my answer around a week. A> Can someone translate that from Russian :) Don't worry, personal medical issues, which are now solved. Russian proverb: "troubles come not alone", so, as result, (was) less attention to FreeDOS development and emailing in groups. A> (It could be some code that the CIA should not see) --- 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel --- 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Information wants to be free
tom ehlert escreveu: Do you really think after having sold thousand copies, I'm a good programmer, who deserves any dollar he makes, and after selling millions copies (and having charged money for it) I'll be suddenly an immoral man ? IMO it will (or propably 'would') still be the same thing: the customer gets some value for some amount of money. if the product is good enough, that the customer is happy - great. if not - not so great. But the customers contentness is probably not related to the fact, that I'm billionaire or not. I believe that being hated as much as "a certain man" is a matter of behaviour. I always use this analogy: Oracle's product are very expensive, but their custumers are content and Oracle is not hated at all. M$ make we feel bad, not because they charge, but because they force us in ways that we want not, or something like that... (I believe that this would happen even if their product was not so bad) 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Information wants to be free
Arkady V.Belousov escreveu: PS: Currently I improve (cure) my nose, so I again delay my answer around a week. Can someone translate that from Russian :) (It could be some code that the CIA should not see) 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel --- 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Patch: Allow seeing ZIP disk serial number
Luchezar Georgiev escreveu: Hello, First, I'd like to express my gratitude to Alain Mouette for his generous donation of an external 100 MB parallel ZIP drive + disks to me which allowed me to catch the bug below. Thank you, Alain! I am very glad that it was usefull. 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] exeflat (2035a) start segment must be variable
Hi Arkady, good to have you back :) Please send me your email address for direct contact. I sent you a message that was probably lost :( 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
So, as a prospective user of the kernel, after contributing to it for more than an year, I can conclude than it's good enough for simpler tasks not involving writing a lot of long named files on a FAT32 partition. For more complex tasks, however, MS-DOS 7.1, PC-DOS 7.1 and ROM-DOS 7.1 are more suitable. You can find a good comparison betweent the different DOS versions on the page of Wengier Wu (åææ, China DOS Union) http://newdos.yginfo.net/dosfat32.htm (page is in English). It gives to me a 404... (though the link seems interesting enough). http://www.google.com.br/search?q=cache:PIFhy-PkmJ0J:newdos.yginfo.net/dosfat32.htm+dosfat32&hl=pt Alain --- 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] commit - UNSTABLE
Hi Arkady, IFM> http://www.fdos.org/bootdisks/autogen/source_core.UNSTABLE.zip BTW, PKZIP can't extract file, if its name contains more than one dot. :( Now I again should binary edit this archive to replace kernel.UNSTABLE.source.zip by something like kernel-UNSTABLE-source.zip... This one can: Official Info-Zip May 2004 release unz551x3.exe26-May-2004 23:22 244K http://sunsite.cnlab-switch.ch/ftp/mirror/infozip/MSDOS/unz551x3.exe I send the URL because I know you need it ;-) 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: patch: cleanups
BO> -void _seg * KernelAllocPara(size_t nPara, UBYTE type, CStr name, int mode) BO> +void _seg * KernelAllocPara(size_t nPara, UBYTE type, const char *name, int BO> mode) This is example, how my shortcuts allows to shorter and, thus, more redable lines. No, Bart is perfectly right. If you use CStr, I first have to lookup what CStr means. It is no "obvious" name for const char *! This actually INCREASES the problems with reading code, unless you first learn all defines by heart. UBYTE on the other hand, for example, is a very obvious name for something which is not signed and 8 bits big. Yes, I also agree here. I have used things like that in tha past and in some cases I even replaces them back to "normal". The problem is that this is grat when you are writing and actively debugging the program this is grat, but 1) after a few years and 2) by someone else, it tends to get harder and harder to understand. One Alternative is to use SetEdit and use itá auto-completion/expand feature to save some typing :) 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: FreeCOM
I vote for it, please... Alain In other words: Only for non-multiconfig we would waste 4 bytes per environment for the sake of being compatible to all programs! I think we *must* pay this price, even though mathematical logics tell use the programs *should* accept \0c:\freecom.com\0 after all. Please re-add such a workaround (old string was "PATH=.\0" I think) instead of forcing us to upgrade all versions of FreeCOM and possibly also other programs. I think saving four bytes of kludge RAM are not worth forcing us all to upgrade FreeCOM. 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Floppy disk read error
Arkady V.Belousov escreveu: Hi! 16-Июл-2004 22:15 [EMAIL PROTECTED] (Alain) wrote to [EMAIL PROTECTED]: A> - if after the error, if I use the "a" option for abort, there is an A> "out of memory error" before returning to command prompt. "Before returning to command prompt" from which program? Note: kernel doesn't contains string "Out of memory". A> Copy (internal of FreeCOM) Looks like bug in FreeCOM. Steffen already fixes some bugs and, I hope, at some time makes fixed edition available to download (without recompilation). A> - made this same test with MS-DOS 7.10 for comparisons And? A> Results are what I explained below, plus that I got no unexpected error Do you use MS-command.com or FreeCOM? As I understand, "no unexpected error" mean MS-command.com in given test? 1) I tested FreeDOS kernel with FreeCOM 2) I tested M$-DOS kernel and commad.com from M$ I will make some mixed tests, the idea is good ;-) A> - If the motor has stopped, it waits a reasonable amout of time before A> showing the error, if the motor is still running (faster retry) it is A> faster. Delays are comparable between FD and M$.>> So, trouble not with FD? Another reason, that your hardware (drive, chipset, cable) is broken. A> Not HARDWARE: I was forcing erros by _removing_ the disks. Same A> procedure with both OSs, to be able to get a comparison. Then I don't understand: you remove diskette while there is copying something, and wish to _not_ get critical errors?! (Of course, "Out of memory" error is bug of FreeCOM, which should be fixed and, probably, already fixed). No what I did was 3 diffenrent things: 1) FreeDOS: I got an error while copying files with normal program install, not so many errors with copy issued by hand (not in batch) 2) Test for comparison 2a) New boot, try to copy a file but removed floppy, note results 2b) New boot with M$-DOS, try to copy a file but removed floppy, note results, compared with 2a) => tested 2a and 2b many times with floppy and without floppy to see what happens in different situations and compare. The out of memory error is coherent with axplained bug in FreeCOM of improper error message. If I abort a copy, _some_ message should get printed, it can just be the wrong text. To be precise, as pointed by tom, in 2035 present bug, which related to critical errors (and it not completely fixed in 2035a), but this bug will look as hungup with message "more than two near fnodes requested at the same time!". Not this one :) A> Can someone send me a debug enabled KERNEL.SYS please? I believe I can I already do this. Isn't you receive k-debug.sys? Just rename it to kernel.sys. A> I didn't receive any kernel shipped to me. Later (after I recompile again) I try to send you (privately) compiled kernels again (and send separate letter with notification about this). But if you not receive this archive again, then I can't help you, because have no other ways beside mail. Please yes, but sent it packed (zip or rar), it could get blocked by some overzealous antivirus. And yes, a separate letter will help to find it. You and also send it cc: to , which is on a diffrent server. I checked all my Spam and Garbadge an found nothing with attachement... 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Floppy disk read error
Arkady V.Belousov escreveu: A> I belive that what Nathan describes below is very close to what is A> happening! No. FD already have retry logic. See dsk.c:LBA_Transfer(): there access repeater up to 5 times (N_RETRY defined in device.h as 5), with fl_reset() between tryings. Ok :( A> - if after the error, if I use the "a" option for abort, there is an A> "out of memory error" before returning to command prompt. "Before returning to command prompt" from which program? Note: kernel doesn't contains string "Out of memory". Copy (internal of FreeCOM) A> - made this same test with MS-DOS 7.10 for comparisons And? Results are what I explained below, plus that I got no unexpected error A> - If the motor has stopped, it waits a reasonable amout of time before A> showing the error, if the motor is still running (faster retry) it is A> faster. Delays are comparable between FD and M$. So, trouble not with FD? Another reason, that your hardware (drive, chipset, cable) is broken. Not HARDWARE: I was forcing erros by _removing_ the disks. Same procedure with both OSs, to be able to get a comparison. A> - before the error FD makes a little more noise (head movements) than A> M$, probably a longer head movement or twice the same movement. Probably, because more retries (5 instead 3). Ok, that is compatible with what I got A> Can someone send me a debug enabled KERNEL.SYS please? I believe I can A> dig out some information with it. I already do this. Isn't you receive k-debug.sys? Just rename it to kernel.sys. I didn't receive any kernel shipped to me. I got kernel 2035a from Lucho's site, a link was posted here. Please send me a link if sending a file is difficult. BTW I believe that this is not affected by new patches, sot it could be 2035 too. 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FAT, Reiser, EXT2/3 and TCP/IP
Norman Bauer escreveu: Given the further enlightenment that I have shed on using FreeDOS as an embedded OS, would you still think that coding the TCP/IP stack into the kernel would not be worth while? Dos in fact is not built that way. This kind of driver can be a TSR and you have all the functionality. That is why Andreas and I decided to make a IPDRV TSR. But remember DOS is single threaded/single task... 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FAT, Reiser, EXT2/3 and TCP/IP
NB> 2. Does anyone know of a project/group that is attempting to build NB> TCP/IP into the FreeDOS Kernel? I don't know, but there are no reason to "built into" TCP/IP into kernel. You always may run TCP/IP drivers in FreeDOS, as in any other DOS. Yes there is. 1) WatTcp: very good and simple. Creates 16 bit executables. Free 2) Watt-32: port of above to create 32 bit executables. Not very good: too complex and buggy (tried and gave up). Free 3) BRAND NEW: from ANDREAS BERGER with a little help from me (mainly testing): very good and very fast. Has a small TSR that handles buffers, inclusive in XMS, and a minor part of IP and ICMP. A library to build 16 and 32 bit executables has the rest. ARP,ICMP ok but basic, UDP is working fine, TCP has yet to be done. This is to be open source if there is interest. 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Floppy disk read error
I belive that what Nathan describes below is very close to what is happening! I made many more tests: - Kernel 2035a 15-jul-04: apparently nothing has changed much - after some time the driver can never more be acessed (this happend after 3rd disk change) - if after the error, if I use the "a" option for abort, there is an "out of memory error" before returning to command prompt. - I made many tests comparing how long it takes to get the message, I removed the floppy sometimes to force an error. - made this same test with MS-DOS 7.10 for comparisons - If the motor has stopped, it waits a reasonable amout of time before showing the error, if the motor is still running (faster retry) it is faster. Delays are comparable between FD and M$. - before the error FD makes a little more noise (head movements) than M$, probably a longer head movement or twice the same movement. A very long time ago, I made floppy access functions (CP/M 2.2) and there is another delay that could be important here: Head stabilising time: after the head moves, it can vibrate a bit so a new retry without head movement can be a good thing. Please note that I am NOT having data erros, I am having NOT READY errors! Can someone send me a debug enabled KERNEL.SYS please? I believe I can dig out some information with it. Alain Nathan Crawford escreveu: I haven't looked at the kernel driver code yet, but here is one possible cause: Back when I was writing floppy drivers for my own OS, I had a problem with a particular floppy not booting on one machine. It would work on the others, but not this particular machine. To fix it, I changed the driver so that the disk operation was checked for success, and if it failed, it first reset the drive with int 13 ax=, and then retried the read. It would do this three times, or until the operation succeeded. On some machines, the operation _MUST_ be immediately retried; the first operation _always_ fails, and only succeeds on the second or third try. Some drives simply can't spin up to speed soon enough. If your driver always makes three tries, the number of times an IO operation actually fails is significantly reduced, and you don't have to prompt the user. -Nathan Do you Yahoo!? Yahoo! Mail <http://us.rd.yahoo.com/mail_us/taglines/50x/*http://promotions.yahoo.com/new_mail/static/efficiency.html> - 50x more storage than other providers! --- 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Floppy disk read error
Arkady V.Belousov escreveu: 1. Do you test 2035a? A> No, please send me the link to it. I just cannot find it. Sources you may find at freedos.sf.net/kernel.UNSTABLE.tgz, compiled image available at Lucho site. Also, Kenneth promise to place image on his site www.fdos.org. If you wish, I send you may compiled edition. There is no binary in the above file. I I need to setup an environment to be able to compile it, I will not be able to do it for a few months more. No kidding, I am in deep s..t up to my neck :( You may recompile with turned DEBUGing and you get a lot of tracing messages on screen. There are no permanently built-in debugging, which may be turned on the fly, especially because this noticeably increases kernel. Can someone send me a compiled version with debugging? Pleeease... Either 2035 or 2035a or both ;-) 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Floppy disk read error
A> I am experiencing a strange problem with FreeDOS, please help me because A> I am not sure how it is happening: 1. Do you test 2035a? No, please send me the link to it. I just cannot find it. 2. Do you test FD with same conditions, as other OSes (for example, if you boot from diskette for FD, do you boot from diskette for MS-DOS7)? Yes. A> When I boot from C:, sometimes (very frequently) when I access floppy A> disk A: I get a message device not ready. I seems to be worse when I A> read 2 floppies sequentianly using a BATCH file that asks for the user A> two swap disks and pauses. Second floppy says not ready, after a few A> retries it starts working, but stops again but accepts retry. Every time A> the floppy drive led does light, I checked. If I copy the same files A> manualy (with copy a:*) it works. This looks like hardware (floppy drive) problem (something like trouble with head moving). It certainly looks like, so I did all the checks including using a brand new driver. It certainly is FreeDOS related. It was _much_ worse with 3034. This does not meen that there is not something wrong somewhere too, but other OS's work, maybe with an automatic retry or whatever. It is probably something wrong + something in FreeDOS that behaves erroniously. A> I really did not understand what happens. My gess is that the floppy A> swap was not detected, but this is not 100% coherent... Do you mean, that drive, probably, not senses diskette change? No, I don't think so - with broken "change line" there are other simptoms. Ok that is an old hw bug. That is not it, behaviour would be different. The problem is that there is no debug option that could help me detect what is really happening. If I could understand it better, I could make a better test. I do have some experience, but I am lost here :( 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Floppy disk read error
Hi Arkady, I am experiencing a strange problem with FreeDOS, please help me because I am not sure how it is happening: K6-2 500, motherboard PcChips (SiS530) this machine works ok with Windows, Dos7.10 and Linux. Floppy drive is new. Kernel 3035. When I boot from C:, sometimes (very frequently) when I access floppy disk A: I get a message device not ready. I seems to be worse when I read 2 floppies sequentianly using a BATCH file that asks for the user two swap disks and pauses. Second floppy says not ready, after a few retries it starts working, but stops again but accepts retry. Every time the floppy drive led does light, I checked. If I copy the same files manualy (with copy a:*) it works. The floppy is ok, I tested with scandisk on another machine. If I boot from floppy it seems to go ok. I really did not understand what happens. My gess is that the floppy swap was not detected, but this is not 100% coherent... please help (anyone), 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel progress
Bernd Blaauw escreveu: Win9x's DOS (7.x0) interprets the keys in a different way compared to older MSDOS. Y = confirm N = not confirm ENTER=confirm ESC = No (MSDOS7), YES (FreeDOS, older MSDOS). so a "don't ask any other items unless explicitly mentioned in config.sys" option/key would have to use something other than ESC. How about the space bar :) ? ..or even..F5 this could do, but I don't like it for a reason: if used at the begining, it meens "Don't execute any or Config.sys os autoexec", so IMHO it thould be something else, something never used, like F7, and F5 could be implemented as "Stop executing any or Config.sys os autoexec" this causes only the commands explicitly using the sequence '?' followed by '=' to be asked: echo?=test (and ?echo=test , but not !echo?=test) Ok, 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel progress
I just reproduce MS-DOS behavior. Also, I myself found that skipping all remaining questions (including "?") is useful. Though, later this behavior may be changed (and documented in config.txt!). In my opinion this would be a _great_ improuvement :) Many times I had ro reboot (in MS-DOS) because the critical instruction was executed ok and I didn't want to singlestep all the rest. BUT, IMHO the key for that should not be but something completely different, like some other function key. 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Re: Kernel bug parade / moving on
Eric Auer escreveu: Hi Aitor, Alain, please ask Lawrence first if the MS DOS kernel clears the 32 bit registers. I bet that it does NOT. I hope he answers this ;-) This is not related to "is the program which breaks unimportant". if it non-existant, then... Alain --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Kernel bug parade / moving on
Aitor Santamaría Merino escreveu:
Eric Auer escribió:
Hi Arkady!
(Clear high parts of 32bit regs...)
How this relates to DOS?
MS DOS basically had no 386 stuff at all (except EMM386). In FreeDOS,
however, people run 386 aware programs more often. Those leave non-zero
values in 32 bit registers when they exit, and the next program which you
start...
Whatever. You are right. Very bad programming practice to expect the high
parts of the 32 bit registers to have some value. I close that "bug
report"
then.
Lawrence comments that this only affected an old version of the
GRDB debugger.
Check out my comment and program on
http://www.freedos.org/bugs/bugzilla/show_bug.cgi?id=1630
Well, I disagree that you should close the bug. The point is: we agree
that it is a VERY BAD programming practice, etc, etc.
But if you implement this (as possibly MS-DOS does), then you get a
system which is more stable, although we are fixing a problem which is
not ours.
I don't think it's a big deal to do a
if (is386+) { XOR EAX, EAX; etc etc}
anyway, or am I missing something?
Aitor
Yes, I agree with Aitor. We recognize it as a bug, if and only if, it
breaks MS-DOS compatibility. That is implicit in FreeDOS manifesto, but
if it only breaks an unimportant program, it can be set to low priority
Alain
---
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel bug parade / moving on
Eric Auer wrote: Hi, while we have no real kernel maintainer right now (I assume Jeremy can at most find enough time to upload patches submitted by others, not for doing coding / testing himself), I think it would be good to review some old bugs before we move on to do new optimizations. Of course now that Arkady already has optimized things: If no new bugs get introduced those patches can of course be added. But I think we should focus on a bit of bug testing and fixing now for a while. I hope there are people on the list who can test some of the issues (i.e. have the affected type of software / hardware around!). YES !!! I also believe that we should focus in buf testing and fixing. We have most of what we need for a Version 1.0. Couldn't that be our goal? Alain PS. I became sudenly very much affraid that so close to the end, we could have FreeDOS to become some kind of _never_ended_ project. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel administration
Could we ask Lucho to come back? He has helped a lot in the past. those that have hes address could write him... Alain Arkady V.Belousov escreveu: Hi! Well, looks like Bart is gone. Who now will manage the kernel (reconcile patches, update CVS, release intermediate snapshots)? For example, my current todo contains at least 6 bugfixes for dsk.c, and 2 which I don't know how to handle. Beside this, there optimized out some hundreths of bytes. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: patch: inthndlr.c
Eric Auer escreveu: Arkady, you really never learn it, do you? Eric, you don't understand: he is russian ;-) Alain --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel fattab.c,1.21,1.22
wcc (wpp neither) can't compile multiple files at the sametime. You can only try to decrease the load time of wcc.exe Maybe compressing it or binding with a dos extender helps. Maybe not. I use it in RAM-DISK (with xmsdsk), allong with all .H files and some more ;-) 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-devel] Re: [Freedos-cvs] kernel/kernel blockio.c,1.30,1.31 dosfns.c,1.61,1.62 int2f.asm,1.27,1.28 proto.h,1.61,1.62 task.c,1.41,1.42
Bernd Blaauw escreveu: Bart distributes 8086 kernels, not 80386 optimized kernels. Lucho does that. Not any more :( Lucho unsubscribed form both FreeDOS list. He was very annoyied about some things here. I would be nice if he received some encouragement messages from some of us ;-) 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Q: release files
Arkady seems to be one of the (few?) people who have no HTTP browser. Perhaps Arachne will work for him on his 80386 system, it's GPL now. (or let Arkady ask someone to send him a more modern computer, right here we are at the 80686 and newer. No idea about transportation costs though.). The bigger problem could be Russian Custums... Arkady, what are the rules there? 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Microsoft beginning to assert FAT Patent
Steve Gibson escreveu: Sorry Arkady, I'm not subscribed to that, so I didn't know. :( I recomend that you subscribe to both. They are in fact somehow conplementary... 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel config.c,1.75,1.76 config.h,1.3,1.4 kernel.asm,1.50,1.51 main.c,1.70,1.71 segs.inc,1.17,1.18 task.c,1.40,1.41
tom ehlert escreveu: Hello Arkady, you really can't keep things untouched? I would really HATE the kernels assembly sources converted into GMOUSE cryptographic sources. Hi Arkady, Tom really has a point here ;-) 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] handle 4 defaulting to PRN???
Luchezar Georgiev escreveu: As always, a patched CVS kernel binary (FAT32, 80386, BC 4.52, aPack) is available in my ROMDSK binary package that can be downloaded at http://linux.tu-varna.acad.bg/~lig/romdsk/romd-bin.rar also got: Forbidden You don't have permission to access /~lig/romdsk/romd-bin.rar on this server. 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] new conv mem highs.
INHO and considering that FreeDOS is in "C" versus all other DOSes being in ASM, I believe that we should just _CELEBRATE_ :) Alain Luchezar Georgiev escreveu: Here's my conventional memory usage by various DOSes after our "great fnode breakthrough": FreeDOS 7.1: 10688 MS-DOS 7.1: 9680 PC-DOS 7.1: 9456 What's in the 760 more bytes of FreeDOS (other than the 2 * 60 = 120 bytes for near fnodes and the 128 bytes for the process 0 stack) and can it be "moved up" somehow? Lucho --- 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: FreeDOS idle HLT
Arkady V.Belousov escreveu: What mean "choke"? You mean, they wrongly handle battery consumptions because CPU starts to eat less power? How this looks? New Power supplies are very cheap. For that they have simplified many important circuits. They don't handle current fluctuations vary well. 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: FreeDOS idle HLT
Bart Oldeman escreveu: On Sat, 27 Mar 2004, Luchezar Georgiev wrote: On Sat, 27 Mar 2004 17:32:19 +0100 (MET), Eric Auer wrote: while you are in an interrupt handler you are in CLI state. So an HLT without a STI before it would hang the system. The _int28_handler is only an iret as far as I remember, and it is shared with int 22 and 2a. I do not think that ALL three interrupts should contain HLT (which usually waits up to 0.05 seconds until the next timer tick happens). So please check that suggestion again... You're right of course, but that was just a rough idea of mine. The labels must be reordered so only _int28_handler goes through the HLT and a STI must be added before it. When Bart fixes the fnodes bug, it will be the right time to start adding little nice features like this one... ;-) I don't know -- there must be a reason why other DOSes don't have this, even while having more comprehensive power saving utilities. Perhaps to guard against TSRs that hook int28 by chaining -- in that case if the HLT comes after the TSR then it may be superfluous... And RBIL is very clear: the default handler is an IRET instruction Certainly not something to implement without a second thought. Also for as long as I can remember Linux kernels check whether HLT actually works as intended, so there may even be broken CPUs out there, and our init code would also need such a check. I'll leave it to FDAPM for now (or if you like a custom small TSR). Yes, better not have neww problems added to the ones we already have. About HLT: nome motherboards (new ones) have a too sudden power consuption drop after a HLT, than the power suply goes crazy and the system hangs... 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] ^Z
Roberto Mariottini escreveu: Hi Arkady, pressing ^Z in non-empty line does nothing (except that line end is ignored), only first ^Z on line is processed as end of input. Strange, but under MS-DOS I get same behavior. Another bug in MS-DOS? I think this is the correct behaviour, IIRC in theory in text files an End-Of-File must always be preceeded by an End-Of-Line. So I think that a Ctrl-Z inside a line (so not immediately after a CR/LF) is interpreted as normal charcter input, with no special End-Of-File meaning. The confusion is still big, as many sources contradict each other on what a "text file" is, and implementations too. For example, Pascal function Eoln is always true if Eof is true, even if ther isn't actually a CR/LF before Ctrl-Z (IIRC). Some very ols OS used ^Z do know the end of the stream and thus close the file. This behaciour can still be found in MS-DOS with the command: copy con: >file where ^Z terminates the input. MS-DOS kernel completely ignores ^Z in any file. I know because of many problems in the past. A CR/LF is not requited before thee ^Z, in any system, just that _usualy_ text files are have CR/LF after the last line. BUT for example some databese programs require a ^Z after the last record of a .DBF file, but other don't require it and some others don't even put it there. One of them (iirc dBaseII) has even a bug that a ^Z in any field sometimes causes the file to get truncated. I hope this helps, 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Primary shell EXIT crashes with invalid opcode
True that once long time ago it was discussed that the rebooting method of jumping to certain BIOS point wasn't "safe" in the sense that wasn't portable across BIOSes, but it was s long time ago that I may be wrong. Thanks :) Well, it _allways_ was sefe and documented to jump to :0, but at the time people were finding "beter" ways of doing 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [spam score 3/10 -pobox] Re: [Freedos-kernel] Primary shell EXIT crashes with invalid opcode
To crash after typing "EXIT" just because I don't have /P on my SHELL line is not very nice! ;-) Agreed. IMHO the crash should be avoided by a) reloading command.com, b) blocking the "exit" command, c) anything ;-) 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Patch: Code wipe bug really fixed at last!
Hi Lucho, Actually, there are two more bugs in FreeDOS I'd like to catch, but they're specific to M$ SCANDISK and RAR-3 so I wonder if it's worth. The first one is that SCANDISK still can't unlock my XMSDSK RAM disk and works only with the /TESTONLY option there. I think I can fix this. The second bug is that RAR-3 doesn't work with wildcards (RAR-2 works). This will be more difficult to solve. Those look a bit like general bugs that can pop up again :( And the problem with some DOS extenders remains, but I don't think that it'll be solved soon. Looks more difficult... Anyway, next week the semester here begins so I'll be probably unable to put significant effort on FreeDOS anymore :-( I just hope you can do something ;-) 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Patch: Code wipe bug really fixed at last!
Luchezar Georgiev escreveu: Thanks - I just found and fixed it, see below! It's allways amazing how small are the fixes for complex bugs like that ;-) Good night now (here it's 10:10PM anyway), and have good (unbugged) dreams, 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [spam score 5/10 -pobox] Re: [Freedos-kernel] Code wipe bug
Yeees, as I say, if you catch a bug, cling to it so that you can kill it before it vanishes... Good luck ;-) Alain Luchezar Georgiev escreveu: On Tue, 17 Feb 2004 15:43:38 +0200, I wrote: I now doubt that the Borland 386 bug is really a Borland or 386 bug. I've found out that the zeroing of the code that calls Kernel() in FreeDOSmain() is done by DosMemFree() at the time free() is called from DoInstall(), because a wong segment is passed to free(). This wrong segment is returned by DosMemAlloc() when called by allocmem() from DoInstall(). So I think that the bug is in DosMemAlloc() and happens only in LAST_FIT mode, which is set just before calling it (through allocmem) in DoInstall(). I now tested a Watcom-built kernel, and the bug is there too, but it just wipes an earlier section of code in FreeDOSmain (the wiped code section happens to be just a bit before the "else" clause), which has already been executed at the time the wiping occurs. Actually, the initial wiping is done by DosMemAlloc() itself when it constructs the MCB. DosMemFree() writes the zeroes there later. So, I'm now sure that the bug is really in DosMemAlloc() and occurs only in LAST_FIT mode. But I can't say exactly where in DosMemAlloc() it is, since I don't understand this function yet. So, we're almost there ;-) Lucho --- 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel --- 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Borland C++ 3.1/4/4.5/5 support
Borland C++ 4.52 builds the smallest compressed kernel - just 41.6 KB for 80386 & FAT32 b.2033 ;-) It has been discussed many times in RtKernel list (RealTimeKernel for DOS 16/32 .exes) that BC 4.52 is the best compiler. The problem as they see it is that Borland C 5 has non-standard start-up code and libraries. At the time they made RtKernel, WatcomC had too many bugs, so it was out of the comparison, but it does have some very strange things, like time_t being unsigned. 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Packing kernel with aPack saves 1.3 KB
Luchezar Georgiev escreveu: On Sat, 31 Jan 2004 15:16:05 + (GMT), Bart Oldeman wrote: I've now prepared the precompiled kernel binary (OpenWatcom 1.2, FAT32, 8086) in ROMDSK this way. (It always contains the latest CVS kernel.) Last note: aPack-ed programs can be freely distributed for non-commercial purposes, but otherwise require a license (the fee is $29 for individual users and $95 for companies, see http://www.ibsensoftware.com/products_aPACK.html). i'm a little worried about this -- this may be incompatible with the GPL! I don't know really. If anyone is competent on licensing issues (albeit not a lawyer) fell free to comment. I have done a not of licence reading and discussed with some lawyers, and my understanding is: If YOU as any specific person is a legal owner of aPack, you can compress it and distribute it without restrictions, including redistribution. But if anyone wants to recompile it he same program he will need to buy it, BUT there is nothing in the GPL that says that GPLed sw has to use free compilers! So, it can be done but will be a major nuisance and should therefore be avoided ... 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Packing kernel with aPack saves 1.3 KB
Hi Lucho, I've now prepared the precompiled kernel binary (OpenWatcom 1.2, FAT32, 8086) in ROMDSK this way. [...] Just for My Information: Aren't Fat32 versions to be compiled in 386 mode (and fat16 in 8086) ? IIRC this was discussed here and the consensus (more or less) was that a machine with more than 2Gb of disk space has to be better than 386, for one that old bios will not support such drivers anyway... 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
