Re: [Freedos-user] FDUPDATE and the 486...
Hi, Has anyone gotten fdupdate to work with a 486? I lost the link to fdupdate v0.55 and the instructions on how to use it in fdupdate v0.54. If using a 486 is the problem because of a bug in the math coprocessor or something similar, that would be nice to know. I've noticed that I get a C prompt back after the crash if I say 387=no in autoexec.bat. I haven't confirmed this, I should test with and without it to confirm. It seems to be true though. Please check if this is the case. Another thing is that you can put em387.dxe or wemu387.dxe or emu387.dxe or so...? The file seems to be emu387.dxe in djdev203.zip ... Somebody in the freebasic forum said: Anyways, in pure DOS (not Windows) I think you can disable the FPU detection for DJGPP by doing set 387=n and set EMU387=c:\mydir\wmemu387.dxe. It should work. I guess other options are putting the dxe in your PATH or in the current directory or the directory where FDUPDATE is etc. Eric -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Abandonware site...
Hi Michael, How about games made for the Tandy Color Computer 3 by Diecom Products? That company is now defunct and has been for a very long time. You can download disk images of Guantlet II. Is that really illegal? As the company is defunct, it is unlikely that they will sue you. But maybe they sold their rights to another company and that one might be interested in getting some money out of you. Or maybe the individual developers now hold the copyright. As long as you have no official statement which makes the once commercial code free, it is not free. Simple. MS-DOS and Windows 3.x are clearly abandonware. If I want to use this abandonware, am I suddenly breaking the law? Not suddenly. It is and was breaking the law. Of course you can hope that MS is too busy hunting people who steal Vista, but you cannot just say that stealing MS DOS is suddenly legal... Busting Grandma for downloading a commercial song she bought a CD of at the local store is a travesty. Yet it happens quite often that some big industry sues some harmless small copying just because they can. I know people who had to pay 100s of Euros for having a picture on their non- commercial private homepage without paying for the rights... The right holder turned out to be a lawyer who apparently had a lot of time to google around and extort amateurs. There was no chance to avoid the fine by just removing the picture after the lawyer complained. Those things just do not work based on what is FAIR. They work based on LAW and there are enough people who do not care about moral rights as long as law gives them money. Eric -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] New problems with Windows 3.1...
Hi Aitor, Eric, was the windows (partial) support ever ported to the stable kernel? (maybe that's why). That partial support is based on heavy patches it seems... As said, the windows 386 mode support even in the unstable kernel is not compiled in by default because it is more experimental than normal unstable. If I don't load emm386.exe, freedos version, I get an error that I have an unsupported dos version. If I try loading windows 3.1 in standard mode, I get an error that there isn't enough extended memory. Did you try using jemm386 instead? And of course: Maybe you do not have too little but too much memory? Himemx and jemm386 support command line options to limit the amount of memory visible to DOS and Windows :-) Do not forget to try DOS=HIGH or DOS=HIGH,UMB or other settings. Note that this is STANDARD mode and not Windows for Workgroups: It should run easily with all kernels including 2036 and 2038 stable, but it can easily fail because of incompatible hardware or drivers. Making Windows 3 run on modern computers and with FreeDOS can be somewhat hard no matter which fancy patches for the kernel you have. You could probably try with MS DOS or Win9x DOS to see what I mean... Eric -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDUPDATEing 1.0?
Hi Mateusz, Is it still possible to use FDUPDATE on FreeDOS 1.0 or to upgrade 1.0 to 1.1? I think FDUPDATE detects when you're running 1.0 and won't update, but I'm not sure how it does this. Yes, it is possible to use FDUPDATE to keep a 1.0 system up to date. However, you won't be able to use it to go from 1.0 to 1.1, as the 1.1 distro will use slightly modified packages. Repositories for 1.0 and 1.1 will be different, too (1.0 will still get its update from http://www.viste-family.net/mateusz/fdupdate/, while 1.1 update server doesn't have an official URL yet). FDUPDATE doesn't know what system it is running on, so it's up to you to use the right version (well, I may add a check of the version, if anyone would be able to tell me how to distinguish in a reliable way a 1.0 install from a 1.1 one...). So: For FreeDOS v1.0 use FDUDPATE v0.54 For FreeDOS v1.1 use FDUPDATE v0.55 (not officially released yet) That sounds like you would have to keep two collections of update packages updated which would be a lot of work. Or like users of 1.0 would be forced to reinstall to get 1.1 ... How hard is it to make FDUPDATE to understand both 1.0 and 1.1 FreeDOS directories? Maybe there can also be a small tool or option to FDUPDATE to do some transformation from 1.0 to 1.1 style, for one time use :-). Eric -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] was: Windows 3.1 - Pending kernel patches 2037/2038
Hi Christian, If you're waiting for further improvements to 2038 before you release 2038, then you're doing this wrong. [...] I'd strongly recommend making 2038 available, and putting the few pending improvements in 2039. The problem is that Eric holds back at least three necessary patches, of There are also patches waiting for feedback / review / testing. Saying you have to modify this like that is one thing, discussion is another. Examples: - handling of floppy before disk is inserted / unformatted partitions - initdisk CHS geometry fix and BSS init fix from RayeR - int 21.1c non-FAT / non-existing drive handling fix from Tom seems Eric doesn't exactly want to be the kernel maintainer, you need someone else for that. Uhm you do not exactly motivate me but I can repeat the state of things: The 2038 kernel needs mainly doc updates plus some feedback for a few small pending patches. The lists are too silent on that. Of course I could just push the patches and assume they will work, but that is the non-preferred choice. The mentioned patches are: None of those patches is necessary for the 2038 kernel but on the other hand some of them are definitely useful, yes :-). - Terminating self-owning PSPs (parent PSP field set to the PSP) doesn't work. There's a patch for this in inthndlr.c but it's wrong and leads to crashes. The patch in inthndlr.c (below case 0x4c of the main Int21 handler) has to be removed, and the condition of a self-owning PSP has to be handled like a TSR termination in the return_user function in task.c. 2037 is affected by this, too. Afair, self-owning PSPs happen in shells and in DEBUG etc, but I do not remember having problems with leaving DEBUG. Leaving the main SHELL is not a good idea anyway. Plus the origins of your inthndlr.c / task.c patch are a bit fishy copyright-wise. - CALL 5 interface is broken, and probably crashes the system. Note that only CP/M programs use this, software from the seventies. The Assembly code in entry.asm that handles such calls is screwed up. I can provide working replacement code or patch it to work how it's supposed to. 2037 is affected by this, too. The patch was long ago and I remember the discussion about it was aborted too early. It should have been on the list, too. I believe it was a do what I say or forget it request ;-). - The seek position (and various other fields) of the SFT isn't declared as unsigned. Eric reported that the seek function reports errors using negative return values. This has to be changed so that it can work with files up to 4 GiB. Depending on when the seek function is called (whether it's already determined that the handle references a valid SFT, and that the origin in al is valid) you might just remove any error reporting of it, since the actual seek operation never returns errors in MS-DOS (as mentioned in RBIL and UDOS too). 2037 seems not to be affected by this, at least the case 0x42 in inthndlr.c should work with larger seek positions. I agree that supporting files above 2 GB size is high on the wishlist and reasonably easy to implement. Will work on it :-) I've CCed the Freedos-kernel list, too. Okay, so I guess I have to CC both lists, too :-) Eric -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Compressed folders?
Hi Robert, 1) ftp://ftp.simtel.net/pub/simtelnet/msdos/arcers/jam125sw.zip JAM is a transparent hard disk compressor, which enlarges your disk space. With the JAM you will forget about annoying messages like 'Insufficient disk space...' with no need to purchase a new hard disk. It only mentions compatibility for DOS versions up to for example MS DOS 7.0 so maybe it does not support LBA or FAT32? The docs do mention many authors so one could ask about that and maybe also about whether they can make JAM freeware. Now it is shareware but free for personal use. 2) ftp://ftp.simtel.net/pub/simtelnet/msdos/execomp/diet145f.zip Link seems to be dead but Garbo has it: ftp://garbo.uwasa.fi/pc/execomp/ 1.2. What makes DIET really unique is its ability to compress DATA Files and to automatically expand them when you call them into an Word Processor or Editor to read or change them. When loaded as TSR, DIET seems to decompress files into tempfiles and redirect access to those. Changes can optionally be compressed again and written back to the original but compressed files. If it is not loaded as TSR, DIET is just an exe packer like UPX and any DIET compressed data files will look broken for your apps because they of course do not know how they are compressed ;-). Still DIET is a classic and probably worth trying. Shareware, but free for personal use :-). I assume it can work with most non-LFN DOS apps. Eric -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] [Freedosuser] FreeDOS localisation project
Hi Roberto, Mateusz, About Freecom: I suppose that CVS version 1.34 2004/12/01 21:20:46 is the same as SVN Revision 1067** SVN gives numbers for the whole state, CVS gives numbers per file. I think you can tell both SVN and CVS to show you the version of everything which was current at 2004/12/01 somehow, though :-). How comes that the ES translation is more up-to date that the EN one? It is possible that the EN file is more a stub because most English messages might also be available in some sort of default message list or even as part of the source code. spanish.lng has 254 translated strings, while english.lng has only 182 Interesting. You should also get in touch with Alain who had worked on reconstructing a Portuguese translation: Sources are lost but we re-extracted the messages from a binary :-). Eric -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Anyone know why 386 enhanced mode doesn't work Windows 3.1???
Hi Jim, I disagree with your No, but you could say it is stable enough statement. The kernel needs to work reliably. Today, we have two branches of the FreeDOS kernel: 2036 stable, and 2037 devel (unstable). That shouldn’t be ok, yet somehow we’ve convinced ourselves this is acceptable. Having two versions of the kernel, where the most recent branch is effectively “broken”, is what’s keeping us from moving forward. Is there a developer on the lists here who has an interest in kernel programming? We need someone who is willing to dig into the code and fix the kernel so we finally have a latest version that's more stable. Is it easier to start with 2036 and re-add the features from 2037? Or is it better to fix the broken parts from 2037, to release a (working) 2038 version? I lack the skill to do any kernel development, so I never tried. I’m hoping someone with the necessary energy and enthusiasm can work it out. The current numbering is that stable plus patches will be 2038 while unstable is 2037 (next unstable will be 2039)... Both branches are based on kernel 2035 and for a while they even both used 2035 as version number(s), unfortunately. While it does not have a SF file release yet, 2038 combines stable 2036 kernel with patches that fix bugs, increase the stability or add small, non-experimental features. It could be released at any time if necessary, but there are some doc updates and small patches what would suit it well :-). The 2037 unstable branch, on the other hand, contains a big number of sometimes complex or unstable patches... A partial list aimed at giving programmers an overview is in the wiki: http://apps.sourceforge.net/mediawiki/freedos/index.php?title=Unstable_Kernel_Branch Any help with making this list more complete is welcome and would be useful both as starting point for people who want to make unstable more stable or add new experimental features in unstable as well as for people who want to backport some of the things from unstable into stable. I think that unstable is too different and too unstable to get a merge soon, but we can work on BOTH branches. For example we can port COUNTRY SYS support from unstable to stable, and the various bugfixes in stable since Jeremy vanished can be ported into the unstable branch while others can start reviewing and cleaning up code in unstable to get it back in view... On the other hand, it might also be an option to keep unstable only for reference and use it as a pool of potential patches which can be put into stable after careful review. As soon as that pool got fished empty, unstable could be abandoned if there are no developers who can give unstable a real future by then. Eric -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Anyone know why 386 enhanced mode doesn't work Windows 3.1???
On Sat, Apr 25, 2009 at 11:31 AM, Eric Auer e.a...@jpberlin.de wrote: [...] The current numbering is that stable plus patches will be 2038 while unstable is 2037 (next unstable will be 2039)... Both branches are based on kernel 2035 and for a while they even both used 2035 as version number(s), unfortunately. While it does not have a SF file release yet, 2038 combines stable 2036 kernel with patches that fix bugs, increase the stability or add small, non-experimental features. It could be released at any time if necessary, but there are some doc updates and small patches what would suit it well :-). So we've moved to alternating between stable and unstable? 2036(stable), 2037(unstable), 2038(stable), 2039(unstable), ... This is not a good practice. Not even the Linux kernel follows the odd numbers are 'devel', and even numbers are stable version scheme. A free / open source software project needs to make frequent releases, with incremental improvements. We should not try to hold a release (like we seem to be doing with 2038.) Release 2038 now, and put those other doc updates and small patches in a 2039 release. -jh -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] was: Windows 3.1 - Pending kernel patches 2037/2038
On Sat, Apr 25, 2009 at 10:59 AM, Eric Auer e.a...@jpberlin.de wrote: Hi Christian, If you're waiting for further improvements to 2038 before you release 2038, then you're doing this wrong. [...] I'd strongly recommend making 2038 available, and putting the few pending improvements in 2039. The problem is that Eric holds back at least three necessary patches, of There are also patches waiting for feedback / review / testing. Saying you have to modify this like that is one thing, discussion is another. Examples: - handling of floppy before disk is inserted / unformatted partitions - initdisk CHS geometry fix and BSS init fix from RayeR - int 21.1c non-FAT / non-existing drive handling fix from Tom seems Eric doesn't exactly want to be the kernel maintainer, you need someone else for that. Uhm you do not exactly motivate me but I can repeat the state of things: The 2038 kernel needs mainly doc updates plus some feedback for a few small pending patches. The lists are too silent on that. Of course I could just push the patches and assume they will work, but that is the non-preferred choice. The mentioned patches are: None of those patches is necessary for the 2038 kernel but on the other hand some of them are definitely useful, yes :-). The problem is: how will you (Eric) know that the patches will work? How long do you intend to hold back the 2038 version before deciding it is good enough? In free / open source software development, the user community assumes a certain level of instability in downloading any version. The idea is that if you release often, you can make rapid, incremental improvements to the F/OSS program because users (testers) will provide frequent feedback to the developers. If you don't make frequent releases, this feedback loop is interrupted, and you lose momentum. If you post 2038 now, and remind everyone that this needs testing (just like any other F/OSS release) then you can get others to help test it and discover bugs ... which can be fixed in a 2039 release. That will probably also have bugs, but you'll address those in a 2040 release. And so on. -jh -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] was: Windows 3.1 - Pending kernel patches 2037/2038
Jim Hall schreef: The problem is: how will you (Eric) know that the patches will work? How long do you intend to hold back the 2038 version before deciding it is good enough? I'd agree with Jim here, release, then ask feedback. People might lack the skill to comment on individual patches, on the implementation within the entire code, and lack being able to compile a kernel themselves. A released kernel + some rough ideas on testcases for the patches would be nice. Bernd -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Anyone know why 386 enhanced mode doesn't work Windows 3.1???
Hi Jim, The current numbering is that stable plus patches will be 2038 while unstable is 2037 (next unstable will be 2039)... Both branches are based on kernel 2035 and for a while they even both used 2035 as version number(s), unfortunately. While it does not have a SF file release yet, 2038 combines stable 2036 kernel with patches that fix bugs, increase the stability or add small, non-experimental features. It could be released at any time if necessary, but there are some doc updates and small patches what would suit it well :-). So we've moved to alternating between stable and unstable? 2036(stable), 2037(unstable), 2038(stable), 2039(unstable), ... To be honest, since Jeremy disappeared I have little hope that there will be a 2039 unstable. I assume that 2039 will instead be a 2038 with some 2037 backport parts added, 2040 will have some more, and so on, until the rest of unstable can hibernate around in peace, waiting for anybody who wants to either make it stable or wants to add more experimental things to it. Maybe possible improved variants of 2037 could be called 2037b etc. This is not a good practice. Not even the Linux kernel follows the odd numbers are 'devel', and even numbers are stable version scheme. It did between 2.0 and 2.6 or so afair. And I must say I do not have the impression that the 2.6.x-y numbers are clear. A free / open source software project needs to make frequent releases, with incremental improvements... We should not try to hold a release There were frequent mentions of the snapshots on the Rugxulo homepage here on the list, but I always hesitated to waste the version number 2038 by making an official SF file release from one of the clearly in-progress snapshots... Yet maybe an official release is the only way to get testers to wake up...? (like we seem to be doing with 2038.) Release 2038 now, and put those other doc updates and small patches in a 2039 release. Will try to push the pending patches from my desktop and other sources into the SVN first, then we can use 2039 for bugfixes if we cannot wait to get test results for that SVN snapshot ;-) Still it is a pity that there was so little discussion on the suggested patches by RayeR, Tom, Christian, (others?) on any list. As said, adding tricky patches without review feels bad. Eric -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Command prompt returns without commands executing
Hi Alex, On Sun, 08 Mar 2009 16:20:40 +0100, I waved a wand and this message magically appears in front of Eric Auer: Indeed a very annoying bug in FreeCOM 0.84 but nobody has yet found a way to predict WHEN it happens. If you can find a way to make it happen at a more specific time than after a while, we could use a debugger to find out what exactly happens when things break. Note that only running com/exe/... (external commands) breaks, you can typically still run internal commands like DIR. Is this the same bug that you are experiencing? Smells like a stack overflow somewhere, methinks, Another option might be overwriteable part of FreeCOM overwritten but FreeCOM failed to notice...? Background: It moves some data to the end of some memory block and when you run a DOS app which does not overwrite that block then FreeCOM can avoid having to restore the data from XMS... There might be some code which decides about whether restore-from-XMS is needed and which is too optimistic. But maybe I am totally wrong about that whole swap/overwrite topic... If the problem can be avoided by not loading EMM386, the cause might be that EMM386 allows some area to be used by DOS (and freecom) as UMB while that area has contents changed by BIOS or because of some hardware activity (sound, network, usb, disk access etc etc)...? Eric -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] chkdsk broken?
Hi Blair, Christian, IIRC chkdsk does not support FAT32 filesystems. This might be your issue. On Thu, Apr 2, 2009 at 1:32 PM, Christian Groessler fdos...@yahoo.de wrote: When I run dosfsck c: it reports everything ok: dosfsck 2.11.DOS, 15 Apr 2006, FAT32, LFN c:: 4191 files, 6623/62597 clusters That is FAT16, clusters are less than 64k. The bug is elsewhere... When I run chkdsk it reports many problems: ChkDsk beta 0.9 Copyright 2002, 2003 Imre Leber under the GNU GPL \KERNEL.SYS has an invalid size, the size should be about 4294901760, but the entry says it's 45341 \COMMAND.COM has an invalid size, the size should be about 4294868992, but the entry says it's 66945 ... This is a known bug from 2003, bugzilla says it would be fixed? www.freedos.org/bugzilla/cgi-bin/show_bug.cgi?id=1633 I do not know what the current version is but a 0.91 exists: www.freedos.org/bugzilla/cgi-bin/show_bug.cgi?id=1954 http://sourceforge.net/tracker/?func=detailaid=2462084group_id=5109atid=105109 That version still fails for drives without subdirectories :-( 2051.178.496 bytes total drive size 3007.194.720 Kb in a total of 3794 files 4294.934.528 bytes in 1 hidden files 13.008.896 bytes in 397 directories 105.676 Kb total size of files 1834.123.264 bytes available on the volume 32.768 bytes in every cluster 62.597 total number of clusters 55.973 number of free clusters Eric -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Anyone know why 386 enhanced mode doesn't work Windows 3.1???
To be honest, since Jeremy disappeared I have little hope that there will be a 2039 unstable. I assume that 2039 will instead be a 2038 with some 2037 backport parts added, 2040 will have some more, and so on, until the rest of unstable can hibernate around in peace, waiting for anybody who wants to either make it stable or wants to add more experimental things to it. Maybe possible improved variants of 2037 could be called 2037b etc. Whatever happens, it is important that new versions of the kernel get released as they happen. Don't wait on 2038 - release it now, and indicate the changes so people can help to test it. If you need to release what you have as 2037b or something, before you feel comfortable releasing 2038, that's fine. But it's important to get the new version out there for people to test. This is not a good practice. Not even the Linux kernel follows the odd numbers are 'devel', and even numbers are stable version scheme. It did between 2.0 and 2.6 or so afair. And I must say I do not have the impression that the 2.6.x-y numbers are clear. They stopped doing the even-odd numbering, because it was too confusing. http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering Where versions are A.B.C or A.B.C.D The old scheme (after 1.0 and prior to version 2.6): * The A number denotes the kernel version. It is rarely changed, and only when major changes in the code and the concept of the kernel occur. It has been changed twice in the history of the kernel: In 1994 (version 1.0) and in 1996 (version 2.0). * The B number denotes the major revision of the kernel o The kernel used the traditional even-odd system version numbering system. * The C number indicates the minor revision of the kernel. This number was changed when security patches, bug fixes, new features or drivers were implemented in the kernel. After the release of 2.6.0 (Dec 2003) it was realized that a much shorter release cycle would be beneficial. Since then: * A and B are largely irrelevant * C is the version of the kernel * D counts from and bug and security fixes (only) to the C version (all development occurs on release candidates—'rc') A free / open source software project needs to make frequent releases, with incremental improvements... We should not try to hold a release There were frequent mentions of the snapshots on the Rugxulo homepage here on the list, but I always hesitated to waste the version number 2038 by making an official SF file release from one of the clearly in-progress snapshots... Yet maybe an official release is the only way to get testers to wake up...? (like we seem to be doing with 2038.) Release 2038 now, and put those other doc updates and small patches in a 2039 release. You aren't wasting a version number. It's just a label. Still it is a pity that there was so little discussion on the suggested patches by RayeR, Tom, Christian, (others?) on any list. As said, adding tricky patches without review feels bad. The review will happen when the version is released. It's possible that the people you mentioned saw nothing needing comment, so did not respond. -jh -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Command prompt returns without commands executing
the data from XMS... There might be some code which decides about whether restore-from-XMS is needed and which is too optimistic. But maybe I am totally wrong about that whole swap/overwrite topic... From what I can tell it always swaps back from XMS and there is no other memory block that I am aware of. If the problem can be avoided by not loading EMM386, the cause might be that EMM386 allows some area to be used by DOS (and freecom) as UMB while that area has contents changed by BIOS or because of some hardware activity (sound, network, usb, disk access etc etc)...? Eric -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
