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] 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] was: Windows 3.1 - Pending kernel patches 2037/2038
Christian Masloch schreef: Since disassembling MS-DOS is considered legal by UDOS and RBIL authors (and these sources are considered legal by all members of the FreeDOS project) I think there's no problem using some DLL examination tool. Regards, Christian I hope you have heared about the term clean room implementation where one team does the research and writes a specification, and another team writes an implementation based on the specification. That way you never violate anyone's copyright, patents etc. Reverse engineering is considered illegal in many countries (DMCA anyone, US folks?). I assume RBIL forms the specification of interfaces, upon which you can build an implementation if you want. Any claim (even without proof) by anyone that FreeDOS is based on infringing Microsoft copyrights can be enough to shut down this entire project, so please keep away from it. ReactOS has had a huge audit because of these copyright infringement claims (which were false, but enough verbosity to taint the project in online media occasionally). I guess the only allowed tools are debuggers for virtual machines, and general debuggers like SoftIce, just to see how software *interacts* with Microsoft copyrighted products. As for running Windows 3.1 on FreeDOS, it's possible. Jeremy Davis managed to do so once a few years ago. Seems like his FDOS.ORG website has expired by now though. Requirements: * kernel 2037, specific compiled flavour of it though * Share, specific compiled flavour. Not sure if it's the FreeDOS one, or the one by Michael Devore, or Japheth, or whoever. * MS memory drivers I think (HIMEM) * FAT16 Your best best would be a MSDOS 6.22 system (only FAT16 support) with Windows 3.1, then add FreeDOS to it (KERNEL, SHARE). Not quite sure if 386-enhanced mode worked, or only standard mode. Speaking of ReactOS, I think they have dropped their 486-compatibility, but still that OS should work on anything which is i80586-compatible (or newer/later). Recent fixes have brought the memory consumption back to about 32MB. -- 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] was: Windows 3.1 - Pending kernel patches 2037/2038
Bernd Blaauw wrote: Christian Masloch schreef: Since disassembling MS-DOS is considered legal by UDOS and RBIL authors (and these sources are considered legal by all members of the FreeDOS project) I think there's no problem using some DLL examination tool. Regards, Christian I hope you have heared about the term clean room implementation where one team does the research and writes a specification, and another team writes an implementation based on the specification. That way you never violate anyone's copyright, patents etc. Reverse engineering is considered illegal in many countries (DMCA anyone, US folks?). I assume RBIL forms the specification of interfaces, upon which you can build an implementation if you want. I'm not talking about disassembling the code. I talking about finding out what the methods are. Visual Studio does it to do intellisence etc. And I believe the tool was provided by Visual C++ 6. I don't want the code for the functions/methods. Just what methods there are and what the parameters are. I can write the internal code myself. I guess the only allowed tools are debuggers for virtual machines, and general debuggers like SoftIce, just to see how software *interacts* with Microsoft copyrighted products. As for running Windows 3.1 on FreeDOS, it's possible. Jeremy Davis managed to do so once a few years ago. Seems like his FDOS.ORG website has expired by now though. Requirements: * kernel 2037, specific compiled flavour of it though * Share, specific compiled flavour. Not sure if it's the FreeDOS one, or the one by Michael Devore, or Japheth, or whoever. * MS memory drivers I think (HIMEM) * FAT16 I would prefer to keep the environments separate. For comparisons etc. I have already gotten the dual boot MSDOS\FreeDos working (just looking on a linux desktop that the laptop will run) Speaking of ReactOS, I think they have dropped their 486-compatibility, but still that OS should work on anything which is i80586-compatible (or newer/later). Recent fixes have brought the memory consumption back to about 32MB. I am hoping that the 486 16bit code will be available in older versions of the source code. I am thinking though it it may be easier to make a 32 bit app that looks like Win 3.x that can run 16 and 32 bit applications. Than to make a complete clone. -- 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] was: Windows 3.1 - Pending kernel patches 2037/2038
On Apr 13, 2009, at 11:29 AM, Adam Norton wrote: Also I remember from my pre dot net days using a program which would inspect a dll and identify all the public methods/functions that it has. Would this be considered legal? If so anyone remember what that program is/was? I used it at a client site to integrate with a 3rd party DLL and application. Any thoughts, advice, windows 3.1 programming SDK, documentation would most helpful. If you aren't opposed to spend a little money, you can go to http://www.powerbasic.com. They still sell (and support) a 16-bit version of their powerbasic for windows, that works with windows 3.x. It also has a program that does what you ask for in identifying all the functions of a dll (at least the ones that can be called by other programs) I don't have my pc in front of me (on the macbook at the moment) so can't get it's exact name, but it works fairly well. I don't remember how much the 16-bit windows version is, (they call it pb/dll or something similar) but I do own a copy, and would be happy to help however I can when you get into working on this clone. (perhaps starting with gem and adding winapis to it would be easier, that way it could run both win and gem programss, but it may be more trouble than it's worth, no idea how much trouble something like that would actually be. -- 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] was: Windows 3.1 - Pending kernel patches 2037/2038
Simple: If you only use WIN /S then you can use the stable 2036 or stable 2038 kernel. The latter is on http://rugxulo.googlepages.com/ as binary snapshot. There are a few pending improvements before 2038 can be put on sourceforge file releases... The sources already are on sourceforge in our svn, of course :-) If there's a stable 2038, then that should get put on ibiblio for general release as soon as possible. If it's on rugxulo's pages, then very few people will know about it (heck, *I* didn't know about it - see my other email.) 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 which two are already provided in source form. He doesn't exactly have to wait for these, we've completely described them. (The first one on the list, others in the FreeDOS bugtracker or old private e-mails.) Since it seems Eric doesn't exactly want to be the kernel maintainer, you need someone else for that. The mentioned patches are: - 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. - CALL 5 interface is broken, and probably crashes the system. 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 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've CCed the Freedos-kernel list, too. Regards, Christian -- 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] was: Windows 3.1 - Pending kernel patches 2037/2038
Windows 3x Issues I was reading the Undocumented Dos book and according to it Win 3.x goes to extraordinary lengths to insure that the operating system it is running on os MSDos and not one of the alternatives. Plus it replaces parts of DOS while running. (Either for underhanded as the book hints at or legitimate concerns it doesn't matter at this point) This probably some of the reason for the problems. Win 3.x will probably never be 100% on FreeDos, nor will a compatible Win 3.x GUI ever be 100%. I have been researching what it would take to make a Win 3.x compatible GUI. I wanted to write a GUI might as well make one that is useful, there are enough new ones out there that are new. I think its possible, and in the long run its probably better. If one runs the Win 3.x /FreeDos then is the GUI/OS that will be unstable. If there is a compatible GUI, then it should be the hopefully rare application that is unstable. Better to have a stable GUI/OS than I think. I think this could be done there is plenty of ports out there to either use or learn from: HX DOS Extender (although there is the lack of license with the source code provided.) Wine Project for Linux Reactos As for the GUI again plenty out there NanoX wxWidgets I have been looking and asking questions on both of the Wine and ReactOS forums and it looks promising. I think I will buy a copy of windows 3.x on EBay and use that for comparison. I can barely remember what it looked like and what is all there. LOL I was thinking of calling the GUI Janus after the code name for windows 3.11. Which I think should be ok legalwise. Thoughts? The lack of license for HX DOS Extender concerns me a bit as well. If code is posted with no license can it be considered public domain? I emailed the author but have not gotten a response. Also I remember from my pre dot net days using a program which would inspect a dll and identify all the public methods/functions that it has. Would this be considered legal? If so anyone remember what that program is/was? I used it at a client site to integrate with a 3rd party DLL and application. Any thoughts, advice, windows 3.1 programming SDK, documentation would most helpful. usul -- 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] was: Windows 3.1 - Pending kernel patches 2037/2038
I was thinking of calling the GUI Janus after the code name for windows 3.11. Which I think should be ok legalwise. Thoughts? hmm you could name it after the Roman god Janus, thinking of looking back to DOS and forward to a GUI? http://en.wikipedia.org/wiki/Janus In Roman mythology, Janus (or Ianus) was the god of gates, doors, doorways, beginnings and endings. His most prominent remnants in modern culture are his namesakes: the month of January, which begins the new year, and the janitor, who is a caretaker of doors and halls. He is most often depicted as having two faces or heads, facing in opposite directions. Janus is believed to be one of the few major deities in Roman mythology that does not have a Greek origin or counterpart. -- 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] was: Windows 3.1 - Pending kernel patches 2037/2038
I was reading the Undocumented Dos book and according to it Win 3.x goes to extraordinary lengths to insure that the operating system it is running on os MSDos and not one of the alternatives. Yes, but note that the described AARD code is not really used in any retail release (UDOS 2nd Edition, p.15) and doesn't really influence the performance of Windows even if it's used. Plus it replaces parts of DOS while running. (Either for underhanded as the book hints at or legitimate concerns it doesn't matter at this point) This probably some of the reason for the problems. Win 3.x will probably never be 100% on FreeDos, nor will a compatible Win 3.x GUI ever be 100%. Some sites suggest to switch off the 32-bit disk access and 32-bit file access (if the used Windows version supports either) because they conflict with larger or newer disks and FAT32. Some other SYSTEM.INI settings regarding DOS critical section handling and stuff might also be useful to setup a stable Windows configuration for a non-MS DOS. I have been looking and asking questions on both of the Wine and ReactOS forums and it looks promising. I think I will buy a copy of windows 3.x on EBay and use that for comparison. I can barely remember what it looked like and what is all there. LOL I was thinking of calling the GUI Janus after the code name for windows 3.11. Which I think should be ok legalwise. Thoughts? Sounds good. The lack of license for HX DOS Extender concerns me a bit as well. If code is posted with no license can it be considered public domain? I emailed the author but have not gotten a response. Well, it's called freeware (including the source code). I think you can use it for anything, but wait for someone else to answer this. Also I remember from my pre dot net days using a program which would inspect a dll and identify all the public methods/functions that it has. Would this be considered legal? If so anyone remember what that program is/was? I used it at a client site to integrate with a 3rd party DLL and application. Since disassembling MS-DOS is considered legal by UDOS and RBIL authors (and these sources are considered legal by all members of the FreeDOS project) I think there's no problem using some DLL examination tool. Regards, Christian -- 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] was: Windows 3.1 - Pending kernel patches 2037/2038
On Mon, Apr 13, 2009 at 11:29 AM, Adam Norton usul.the.mo...@gmail.comwrote: Windows 3x Issues I was reading the Undocumented Dos book and according to it Win 3.x goes to extraordinary lengths to insure that the operating system it is running on os MSDos and not one of the alternatives. Plus it replaces parts of DOS while running. (Either for underhanded as the book hints at or legitimate concerns it doesn't matter at this point) This probably some of the reason for the problems. Win 3.x will probably never be 100% on FreeDos, nor will a compatible Win 3.x GUI ever be 100%. I have been researching what it would take to make a Win 3.x compatible GUI. I wanted to write a GUI might as well make one that is useful, there are enough new ones out there that are new. I think its possible, and in the long run its probably better. If one runs the Win 3.x /FreeDos then is the GUI/OS that will be unstable. If there is a compatible GUI, then it should be the hopefully rare application that is unstable. Better to have a stable GUI/OS than I think. I think this could be done there is plenty of ports out there to either use or learn from: HX DOS Extender (although there is the lack of license with the source code provided.) Wine Project for Linux Reactos As for the GUI again plenty out there NanoX wxWidgets I think Nano-X is a good thing to choose, but for the widgets UI base, I would instead suggest Qt. Qt is more stable, so less reason to possibly fork it. Plus, it's just a CSS file away from being restyled to look like Windows 3.1x! Plus, Qt is a complete framework, so you could literally implement the entire API as a front end to Qt itself, which would increase portability. I have been looking and asking questions on both of the Wine and ReactOS forums and it looks promising. I think I will buy a copy of windows 3.x on EBay and use that for comparison. I can barely remember what it looked like and what is all there. LOL First: http://www.guidebookgallery.org/screenshots/win311fw ( :P) Second: http://www.weblust.com/winbible/BibleTop.html Third: http://eburl.net/8958b Any thoughts, advice, windows 3.1 programming SDK, documentation would most helpful. usul I do have a copy of the Windows 3.1 programming SDK on a backup disc, which came with a copy of MSVC 1.52c Maybe that would help? Also, a few links to help ya out: One: http://eburl.net/8b1e6f Two: http://eburl.net/275fe Three: http://eburl.net/ce66 Hope these help! -- 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
