Re: [Freedos-kernel] More kernel bugs and incompatibilities
At 11:35 PM 8/11/2004 +1200, Bart Oldeman wrote: And with that, I'm at the end of the list for finding FreeDOS incompatibilities unrelated to kernel, shell, and stand-alone FD utilities again. There's one FD incompatibility that's been there for some time: OpenWatcom wd /tr=rsi and wd /tr=cw appear to run just fine when you debug a program but a crash occurs (black screen, reset only way out, or invalid opcode) when you exit the debugger. This doesn't happen with MSDOS. I'm taking the coward's way out here. This happens even without EMM386 or HIMEM, so it about has to be an incompatibility in the kernel. Which gets me off the hook and re-clears my personal checklist. I could try and debug it anyway, but again plead ignorance of detailed kernel workings. A kernel developer would be the best victim..errr...person to track this incompatibility down. I did notice that DOSEMU also has, or had, a problem with child 4Ch termination under WD and that would be my best guess for a starting place on what's going on with WD and FreeDOS. --- 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] HiNTOS
At 02:22 PM 8/11/2004 +0300, Luchezar Georgiev wrote: HiNTOS is a DOS extender and Windows emulator that converts Windows console programs into programs that run in both Windows and DOS. It's the only one that can convert *fixed* PE executables (WDOSX can't!). It's available at http://www.alex-hint.narod.ru/hintos-e.html and I think it's becoming more and more important now when everybody releases Windows console programs without DOS counterparts. I converted successfully with it: Digital Mars C/C++ 8.38, MASM 6.15 and RAR 3.30 (its DOS version fails to modify existing archives but its Windows console version can do it). HiNTOS works under MS-DOS, PC-DOS and ROM-DOS, but not under DR-DOS and FreeDOS. To make it run under FreeDOS, the kernel will have to be rewritten not only to show SFT data to the outside world but also to work with this data internally as MS-DOS does. This won't happen soon, if at all :-( Given sufficient demand, some young hotshot programmer might be able to write a compatibility wedge for it if the code was open-sourced or the SFT req was fully spec'ed out . I don't know though, the software doesn't look ready for endusers other than experimenting types. --- 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
At 11:35 PM 8/11/2004 +1200, Bart Oldeman wrote: There's one FD incompatibility that's been there for some time: OpenWatcom wd /tr=rsi and wd /tr=cw appear to run just fine when you debug a program but a crash occurs (black screen, reset only way out, or invalid opcode) when you exit the debugger. This doesn't happen with MSDOS. Guess I can download and copy it over to the FreeDOS machine. I'm back to average Joe User for all that stuff since my custom CauseWay and Watcom development machine setup had a very noisy and severe hard disk crash last month. Since no mission critical data was lost, I declined Ontrack Data Recovery's kind offer to recover the files from the magic magnetic fairy dust for the low low discounted price of $1600.00. Something about being able to get a much nicer new hard drive with a fairly powerful computer wrapped around it for the same amount of money made the process seem less worthwhile. Which is a roundabout way of saying that probably in the next day or three I'll grab the latest files from OpenWatcom and install there for testing. --- 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
At 01:02 PM 8/8/2004 +0300, Luchezar Georgiev wrote: Borland 32RTM 1.5 fails to work in FreeDOS but works in MS-DOS. I've patched it to make it work by modifying the byte at offset 284h from 0 to 1. The X32 DOS extender used in Digital Mars SMAKE had caused problems, so I've patched its offset 4707 from 23h to Bh, but right now when I test it, it works! (So somehow the bug got fixed during the last year ;-) Last not least, since it modifies the SFTs, the HiNTOS DOS extender (or Windows to DOS converter) doesn't work at all in FreeDOS. Alas, I did my patches more than an year ago and I don't remember how I found out these offsets :( More specifically, I would need download access to an application which fails when running under these (or any) extenders, rather than the bare extender itself. Without the context of the CPU instruction or data being patched and what the patch is meant to do, an offset and byte punch value is of no use for externally tracking down and correcting the underlying problem. --- 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] Win3.x /3 investigations, /s ones, cool 386SWAT debugger
At 06:39 AM 8/9/2004 +0200, Eric Auer wrote: I was able to learn more about Win32 loading in Win 3.1 / German this weekend. For me, the PCI/AGP bus magic for flipping and initializing cards *crashes* with MS HIMEM (3.07, comes with Win3.1) *unless* you also load MS EMM386 (4.44, same source), strange. Whatever. Then in Win3.x itself, there are some checks at - for me - 8028dfec/8028e067/8028e10b: first a lookup table for known properties (only contains DOS 4.00 it seems), An unanswered question is are you able to successfully install Windows 3.1 itself over FreeDOS? Attempting to do so here aborts the install while it is within the initial stages of running Windows after preliminary DOS file copies on disk 1 and 2. There is a fatal general protection or stack fault which consistently stops the process. --- 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] Re: 32RTM BitMixer feature incompatibility
At 10:56 AM 8/10/2004 +0300, Luchezar Georgiev wrote: Hello Michael, More specifically, I would need download access to an application which fails when running under these (or any) extenders, rather than the bare extender itself. The whole Borland C++ 5.02 is in Vietnam at http://www.saigontech.net/users/htliem/BC502/ The only files you need from there are UNPAQ.EXE (48 KB) and DPMI32.PAK (110 KB) containing 32RTM.EXE, because if you make 32RTM.EXE successfully load by itself without the -X (disable BitMixer) switch, the problem is solved. In short, the problem is getting its BitMixer feature work under FreeDOS. This is explained below. Well, UNPAQ.EXE says it needs 32RTM.EXE when executed and DPMI32.PAK just sits there completely inert, so apparently there is a bit more to the process than having the two files. --- 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] Re: 32RTM bug
At 11:12 AM 8/11/2004 +1200, Bart Oldeman wrote: On Tue, 10 Aug 2004, Michael Devore wrote: Some way or another, it looks 32RTM is unhappy with what is going on with the stack on the call to function 34h. I don't think the InDOS pointer itself is what causes the failure because the exception can occur during or immediately after return from the Get InDOS simulate call. From your story it sounds that the int21 entry code uses too much space on the user stack. Before someone invest too much of their life, I suppose the location could be an artefact of the debugger interacting with InDOS, but it doesn't look like it. After RTM goes into (16-bit) protected mode and installs a DPMI server, any breakpoints I place with 386SWAT wind up at an IRET (apparently because of the dual nature of what IRET does and confused real mode/pmode issues with the debugger). If I breakpoint right before the INT 31h simulate real call function, I get the expected IRET. Placing a breakpoint immediately after gets the exception and termination feedback. Can't see how it would be other than that INT 31h function which is the problem. I tracked down the actual exception location reported. It's on a REP MOVSW, as is very typical. Possibly occurs in the DPMI interface which copies values to/from low memory. Not much help, that. And for all I know, this could be a bug in RTM which is masked in MS-DOS because of a larger or differently structured stack, or other internal image difference. --- 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] Re: 32RTM bug
At 06:44 PM 8/10/2004 -0500, I wrote: At 11:12 AM 8/11/2004 +1200, Bart Oldeman wrote: On Tue, 10 Aug 2004, Michael Devore wrote: Some way or another, it looks 32RTM is unhappy with what is going on with the stack on the call to function 34h. I don't think the InDOS pointer itself is what causes the failure because the exception can occur during or immediately after return from the Get InDOS simulate call. From your story it sounds that the int21 entry code uses too much space on the user stack. Before someone invest too much of their life, I suppose the location could be an artefact of the debugger interacting with InDOS, but it doesn't look like it. Problem is definitely the INT 31h simulate real mode interrupt Get InDOS function. If I patch out the function to simply put a zero in the returned ES:BX pointer, 32RTM goes resident without kicking out an exception. Of course, it no longer uses the InDOS flag properly, assuming it ever does use it. Anyway, that's as far as I can go with what I see. It's a problem with INT 21h DOS function 34h when called from pmode through the Borland DPMI server via INT 31h. Hopefully a kernel person can either fix it or call shenanigans on Borland. --- 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
At 01:02 PM 8/8/2004 +0300, you wrote: Last not least, since it modifies the SFTs, the HiNTOS DOS extender (or Windows to DOS converter) doesn't work at all in FreeDOS. This is either a really obscure extender or else also known under a different name, as even Google Usenet search doesn't pick up a hint of it. But it doesn't sound like it's a current issue for anyone. And with that, I'm at the end of the list for finding FreeDOS incompatibilities unrelated to kernel, shell, and stand-alone FD utilities again. --- 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] Re: Win3.x /3 investigations, /s ones, cool 386SWAT debugger
At 05:38 AM 8/11/2004 +0200, Eric Auer wrote: An unanswered question is are you able to successfully install Windows 3.1 itself over FreeDOS? Attempting to do so here aborts the install while it Yes I were able to do that. I copied all disk contents into 7 directories first (because I got an original and therefore very old pile of disks and I wanted to have a backup first). Then I copied all 7 directories into one directory, and started the install process from there. Of course I selected manual / custom installation, and used some sane / generic drivers (VGA16, LMouse, no network...) at first. Everything worked okay, even MSD worked (looks as Seems to be very flakey and system dependent. Here, WINSETUP consistently fails during init into GPF, even with vanilla setup and true-blue MS-DOS HIMEM and EMM386, or no EMM386 present. It starts Windows to get name and option install info during initialization process, but that's as far as it goes. --- 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
At 09:19 PM 8/7/2004 +0300, Luchezar Georgiev wrote: Needless to say that these bugs and incompatibilities are only a small part of the whole picture. You already know the DOS extender compatibility problems I've reported earlier. Perhaps it's also worth mentioning that writing files under DOSLFN is significantly slower than under MS-DOS. I'd like to know of any DOS extender compatibility problems as I have looked carefully for them. All the big name extenders and several 2nd or 3rd tier ones, work fine for all the applications tested. Eric Auer remarks that DOS/4GW still has compatibility problems in Bugzilla, but he has failed to demonstrate any of them to me. --- 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] ludivmul.inc
At 12:55 AM 7/20/2004 +1200, Bart Oldeman wrote: I'm sorry but I simply don't have the time to go through all the other patches. If they were reduced to just bug fixes I'll promise that I'll have another look though -- I still monitor the mailing list every now and then. Guys *any* project that wants to be close to a 1.0 release must be in deep freeze, a stabilation, that means that we should really freeze the mainline kernel for anything but bug fixes. No optimizations, no reformatting, no new fancy macros, no nothing but bug fixes with the minimal amount of lines changed. Of course feel free to have your own branch, but I don't think it's in the interest of the project to use that for a 1.0. I am glad someone said this that nicely. I have been stunned that the vast number of relative last-minute pre-1.0 kernel changes which do not consist mostly of bugfixes or user-driven requests/needs has been considered a good idea by anyone. Items such as multiple stand-alone changes to source code comments which only change indentation levels or add a trailing tab are egregiously unnecessary when considered immediately prior to FD 1.0 release. On the other hand, this is exactly the sort of issue that kills so many open source developments. The talent butts heads over what needs to be done, no compromise can be achieved, and one group of talent splits away or quits in disgust. It would be very disheartening to see that happen (again) with FreeDOS, particularly given how close it is to 1.0. I don't work on kernel and have kept quiet until now because of that, but as this whole mess appears to be coming to a crisis, my modest addition to the discussion is this suggestion: perhaps self-tested optimizations can be included along with bugfixes and enhancements, since they actually affect code and give the programmer an opportunity to stamp the code with and demonstrate his talent? --- 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=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-devel] Re: Intel PRO/1000 driver fails under FreeDOS
At 07:08 PM 4/25/2004 -0400, Patrick J. LoPresti wrote: Michael Devore [EMAIL PROTECTED] writes: I don't do kernel work, but depending on how much you want to dig in the guts of the problem, you might want to grab the 386SWAT debugger and load it immediately after the driver, with nothing else. It should catch the exception and throw you into the 386SWAT debugger. After paring down my boot disk, I got 386SWAT to fit (with 2K to spare). And by invoking it with DEVICE=A:\386swat.lod TRAPINV, I actually get thrown into the debugger where I used to get invalid opcode + reboot. So it's a start. But I really have no idea what I am looking at... First thing to look at is the register values, which are across the top line. We need those values. Then look at the failing CPU instruction line which is highlighted in the main window. That together with the register values should give the immediate reason for failure. The EFL flags value right above the main window would be good info to know, too. --- 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] 2034rc feedback (and EMM386)
EMM386: FDISK /REBOOT causes Invalid Opcode, FDAPM WARMBOOT does the same Need to know the Invalid Opcode data to do anything about it, if can be. --- 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=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
