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] 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] 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] Anyone know why 386 enhanced mode doesn't work Windows 3.1???
On Sunday 12 April 2009 02:35 (CEST), Eric Auer wrote: FDUPDATE is written in FreeBASIC and FreeBASIC might have issues if your CPU has no or no relatively modern FPU... I think Rugxulo knows a workaround for that and will mail about the issue with Mateusz. Hi, I really don't think it has anything to do with the used CPU type... FreeBASIC compiler is happy when it gets anything 386-compatible (IIRC FreeBASIC is emulating a FPU when none applicable has been found). Besides that, in another mail (maybe it was a mail to me only, can't remember if got its way to the list), the OP wrote that FDUPDATE is crashing when trying to apply an update. Therefore: - FDUPDATE starts correctly, - FDUPDATE makes wget downloading the index file from my server correctly, - FDUPDATE open the index file and load the package database correcyly, - It propose an update, basing on what has been found on user's system, - crash when launching wget to download that given package. So FDUPDATE is crashing the *second* time it run wget. Sounds odd. Could be indeed some open file left thing, but I carefully checked FDUPDATE's code, and it is closing any opened files in a clean way before calling wget/curl. I compiled a beta testing FDUPDATE v0.55 version, which is able to make use of HTGET as a downloader, hoping that it would resolve the trouble, but got no feedback yet about how it works (or not works). See you, Mateusz VIste -- You'll find my public OpenPGP key at http://www.viste-family.net/mateusz/pub_key signature.asc Description: This is a digitally signed message part. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Anyone know why 386 enhanced mode doesn't work Windows 3.1???
Com1/3 and 2/4 share the same irq. If you want to use them simultaneously, you'll need to change the irq they use. This would make them non-standard, but there are programs that can add com 3-4 to your bios port table area, and thus make them viewable by normal dos apps. I used to have it, but no longer do, although I'm sure a search on google will turn up a copy. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Anyone know why 386 enhanced mode doesn't work Windows 3.1???
On Sunday 12 April 2009 16:32 (CEST), Adam Norton wrote: Is internet access required for FDUPDATE? Or can the files be on a CD? Hi! The whole idea is to get updates ONLINE... So yes, you have to be networked to let FDUPDATE contact the FreeDOS updates server... If you already have files on a CD, you may simply use FDPK to install them. Best regards, Mateusz Viste -- You'll find my public OpenPGP key at http://www.viste-family.net/mateusz/pub_key signature.asc Description: This is a digitally signed message part. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Anyone know why 386 enhanced mode doesn't work Windows 3.1???
Is internet access required for FDUPDATE? Or can the files be on a CD? - FDUPDATE makes wget downloading the index file from my server correctly, - FDUPDATE open the index file and load the package database correcyly, - It propose an update, basing on what has been found on user's system, - crash when launching wget to download that given package. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Anyone know why 386 enhanced mode doesn't work Windows 3.1???
On Sat, Apr 11, 2009 at 7:35 PM, Eric Auer e.a...@jpberlin.de wrote: Hi, Using MS-DOS 6.2x himem.sys and MS-DOS 6.2x emm386.exe, I have Windows 3.1 running on freedos 1. What I wonder is why 386 enhanced mode errs out with incorrect dos version??? I'm using the unstable kernel that came with freedos 1. Is anyone working on it to get it stable? No, but you could say it is stable enough for you ;-) The main problem is that you need to use the WINKERNEL from 1.0 which is the unstable kernel but with those extra experimental 386 enhanced patches activated. You may also have to: Load SHARE, not load EMM386, or use the MS versions of EMM386 and/or HIMEM. The latter two might be tricky to configure right on modern hardware. [...] 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. -jh -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Anyone know why 386 enhanced mode doesn't work Windows 3.1???
Hi, Using MS-DOS 6.2x himem.sys and MS-DOS 6.2x emm386.exe, I have Windows 3.1 running on freedos 1. What I wonder is why 386 enhanced mode errs out with incorrect dos version??? I'm using the unstable kernel that came with freedos 1. Is anyone working on it to get it stable? No, but you could say it is stable enough for you ;-) The main problem is that you need to use the WINKERNEL from 1.0 which is the unstable kernel but with those extra experimental 386 enhanced patches activated. You may also have to: Load SHARE, not load EMM386, or use the MS versions of EMM386 and/or HIMEM. The latter two might be tricky to configure right on modern hardware. I'm still getting the 2 near fnodes error with fdupdate. If I could look at the source for fdupdate 0.54, maybe I can figure out where it crashes. FDUPDATE is written in FreeBASIC and FreeBASIC might have issues if your CPU has no or no relatively modern FPU... I think Rugxulo knows a workaround for that and will mail about the issue with Mateusz. Eric -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Anyone know why 386 enhanced mode doesn't work Windows 3.1???
On Friday 10 April 2009 10:24 (CEST), Michael Robinson wrote: I'm still getting the 2 near fnodes error with fdupdate. Do you tried the beta 0.55 version I sent you few days ago (the one using HTGET as a downloader)? Still crashing? If I could look at the source for fdupdate 0.54, maybe I can figure out where it crashes. FDUPDATE is an open-source project, so feel free to contribute :-) Of course do not forget to send me any patches you could possibly came up with, I will merge them into the official release. FDUPDATE's source is available for download at http://mateusz.viste.free.fr/dos/en/download.php?plik=fdupdate Best regards, Mateusz Viste -- You'll find my public OpenPGP key at http://www.viste-family.net/mateusz/pub_key signature.asc Description: This is a digitally signed message part. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Anyone know why 386 enhanced mode doesn't work Windows 3.1???
On Fri, 2009-04-10 at 10:34 +0200, Mateusz Viste wrote: On Friday 10 April 2009 10:24 (CEST), Michael Robinson wrote: I'm still getting the 2 near fnodes error with fdupdate. Do you tried the beta 0.55 version I sent you few days ago (the one using HTGET as a downloader)? Still crashing? Just to be clear, I need to wait for Freedos 1.1 before I use the 0.55 beta version? I've tested curl on a large file and it did okay. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
