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] More kernel bugs and incompatibilities
Hi Tom, one reason for different behaviour *might* be that smartdrv traps int25/int26, which is used differently in FreeDOS (not everything is rooted through it) I don't think other DOSes route things through int25/int26 either, I tested that a few years ago. It would be a major headache anyway as int25/26 would reset the DOS stack pointer! RBIL explicitly mentions 480h 384 BYTEs disk stack (functions greater than 0Ch, INT 25,INT 26) in the SDA. To make a long story of Eric short, later versions hook at the device driver level, ie. what execrh.asm calls for FreeDOS. Searching a bit on google groups: interesting, this link talks about smartdrv but also about config.sys processing order: http://groups.google.com/groups?selm=1993Mar12.001843.20281%40microsoft.com Jen Kilmer posted more informative posts about smartdrv. If you even go further back you find posts from Mark Zbibowski (MZ) e.g. http://groups.google.com/groups?selm=8697%40microsoft.UUCP from 1984. Bart -- Usenet is a strange place -- Dennis M. Ritchie --- 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
[Freedos-kernel] Re: 32RTM BitMixer feature incompatibility
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. 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. As I wrote in a later post, I finaly remembered that the problem was in the so-called BitMixer. If you load 32RTM -X disabling it, it loads successfully. If load it without -X, it fails saying Unhandled exception 000D at 0020 034B ErrCode 000. My patch just changes the flag at offset 284h of 32RTM.EXE which controls if BitMixer is enabled by default from 0 (enabled) to 1 (disabled). Good luck! Lucho --- 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
On Tue, 10 Aug 2004, Bart Oldeman wrote: I don't think other DOSes route things through int25/int26 either, I tested that a few years ago. It would be a major headache anyway as int25/26 would reset the DOS stack pointer! RBIL explicitly mentions There is yet another thing why DOS cannot use the plain INT-25/26 (maybe some internal counter function): ASSIGN hooks all three INT-21/25/26, hence, rewriting would take place twice. Bye, -- Steffen Kaiser --- 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
Hallo Bart, if the partition table loops (recursive problem), MSDOS just hangs but FreeDOS checks for it and happily uses the partitions that are fine. Of course, there are bugs in MS-DOS that are not present in FreeDOS. But I think that the main problem of the FreeDOS kernel are not bugs, but incompatibilities, e.g. with DOSLFN 0.33. Some of them will never be solved, e.g. the code patterns which Windows 3.1 looks for that Eric mentions will NEVER be there, nor should they be there, of course. Not to mention the fact that the FreeDOS kernel's disk and memory footprints (40K vs. 50K in HMA) are smaller than those of MSDOS 7.10. The HMA footprint doesn't count much if a disk cache is used, because the number of buffers that HMA is filled in doesn't matter then. Microsoft even recommends that an explicitly low number of buffers is used in this case (e.g. 8). The disk footprint counts much more, but not always. For example, if someone wants to embed the kernel into the BIOS (which turned out much more difficult than I thought, as modern BIOSes won't allow ISA option ROMs!) it counts a lot. It counts for boot diskettes too, but not for hard disks. Regards, Lucho --- 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: Will FreeDOS work from a primary slave partition?
Hi! 10--2004 10:02 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: BTW, what if FreeDOS will search (fd)config.sys not on C:, but on real bootable partition? Kernel knows which disk was used to boot (currently not preserved - at start of main.c:FreeDOSmain() LoL-BootDrive initialized to 1..3 for A:,B: and C:), and initdisk.c:ReadAllPartitionTables() may compute, which partition is booted from boot drive, so before calling DoConfig() consequent drive (instead C:) may be selected as default. Any objections? LG Isn't the real bootable partition always assigned to C:? Not completely. See initdisk.c:ReadAllPartitionTables() - in case of MS-DOS order there always searched first primary active partition on _first_ disk. (If there is no active partition, searched any first primary partition). Only in case of (FreeDOS featured) sorted by drives Drive Letter Assignment FreeDOS assigns C: to _real_ active partition (see how first loop searches real boot drive). BTW, I think this (slightly) misleading, when (boot) partition from secondary disk becomes C:. Again, I suggest, probably, better to _not_ make it C:, but in main.c:FreeDOSmain() make it default (to allow process (fd)config.sys from it). LG Let's concentrate on bgfixing before the imminent FD1 release. I not object, but this question may be studied _for future releases_. Isn't? :) --- 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
[Freedos-kernel] Re: Re: Will FreeDOS work from a primary slave partition?
Hello! Isn't the real bootable partition always assigned to C:? BTW, I think this (slightly) misleading, when (boot) partition from secondary disk becomes C:. Again, I suggest, probably, better to _not_ make it C:, but in main.c:FreeDOSmain() make it default (to allow process (fd)config.sys from it). Not a bad idea. Let's concentrate on bgfixing before the imminent FD1 release. I not object, but this question may be studied _for future releases_. Isn't? :) Sure. All suggestions here are for a post-FD1.0 release. EA the config file can contain a (processed in 0th pass) EA BOOTDRIVE=X line which makes FreeDOS select drive X: and EA load the config file from there for the other passes. Or it can even implement the ROM-DOS's NEWFILE= CONFIG.SYS command. Below is the relevant for NEWFILE excerpt from http://www.rtdusa.com/NEW_manuals/software/cpumodules/ROMDOS_manual.pdf Lucho __ NEWFILE CONFIG.SYS Command The NEWFILE command allows you to continue CONFIG.SYS file processing from a new file. The file can be located in another directory or even on a different drive. Syntax NEWFILE=filename[,device] Remarks The NEWFILE command is especially useful when the CONFIG.SYS file is located on an inaccessible drive or in ROM. Additional device drivers or instructions can be added easily to the new file and is processed along with the main CONFIG.SYS file upon starting the system. When the NEWFILE= instruction is processed, control passes from the present file (the one containing the NEWFILE instruction) to the file specified in the command. Any commands placed after the NEWFILE instruction in the original file are not processed. If the specified filename cannot be located, CONFIG.SYS processing returns to the original CONFIG.SYS file and the next instruction is processed. The next instruction can even be a second NEWFILE= statement, allowing flexibility for systems which may have a variety of drives installed or not installed at boot time. The first successful NEWFILE statement is processed, transferring control to the specified filename. The remaining instructions in the original CONFIG.SYS file, including NEWFILE= statements, are not processed. When NEWFILE is used, it is also created as an environment variable, retaining the value assigned by the NEWFILE= statement. This can be used in an AUTOEXEC.BAT file for further boot-up decision-making. The presence of [,device] on the NEWFILE command line will tell the ROM-DOS kernel to load this device driver before trying to process this NEWFILE statement. The format of this parameter is exactly the same as the parameter for a DEVICE= statement. Examples NEWFILE=C:\BIN\NEWCFG.SYS Causes instructions in the file NEWCFG.SYS, located in the C:\BIN directory, to be executed as part of the CONFIG.SYS file. NEWFILE=C:\BIN\NEWCFG.SYS,ROMDRIVE.SYS C000 Causes the device driver, ROMDRIVE.SYS, to be executed prior to processing the instructions in the file NEWCFG.SYS as part of the CONFIG.SYS file. Also, the environment will contain the following entry: NEWFILE=C:\BIN\NEWCFG.SYS Verify this by running the SET command with no parameters. NEWFILE commands can be nested. That is, your original CONFIG.SYS can call a second set of instructions via the NEWFILE command. The second file can, in turn, call a third file by using the NEWFILE command, and so on. Be sure that each filename in the successive steps has a unique name, otherwise, you will create an infinite loop as control is passed back to the same file repeatedly. --- 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
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. The only place I could find in entry.asm where this could be a problem is in - ; ; end Dos Critical Section 0 thur 7 ; ; dos_crit_sect: mov [_Int21AX],ax ; needed! pushax ; This must be here!!! mov ah,82h ; re-enrty sake before disk stack int 2ah ; Calling Server Hook! pop ax ret - I don't understand the comments here. Who wrote this code? Does re-enrty sake before disk stack mean that this code has to be executed on the user stack? Anyway, one could experiment by commenting out all call dos_crit_sects in entry.asm. Bart --- 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
[Freedos-kernel] 2035 findfirst bug: attr a8 treated as 08 if local
Hi, I am having with the load saved game function of a jump and run game... The game modifies the timer speed, hooks int 8, 9, 60, 61, 23 and 24, calls functions (ax) 0..6 of int 60 (int 61 is used quite a lot but does not seem to have function number in ax properties), uses functions 0 and 1 of int 16 ... Graphics modes are numbers 2, 5, 6, 9, 13 (i.e. when you exit to DOS you end up in 80x25 mono, CGA uses cyan/magenta 320x200 (and - when? - 640x200), Tandy uses 320x200x16 (? - there are also std (speaker), Adlib and PCjr sound and music drivers and mt (port 330/331 - MIDI?) music drivers), MCGA is supported and EGA is upported (640x350 I think). Palette access is done with int 10 functions 1002 / 1010. There is direct access to ports and memory for graphics and sound and timer. As far as I can tell, the only other used DOS resource are int 21 functions: 02 06 0d 09 10 1a 25 30 35 3c 3d 3e 3f 40 42 48 49 4b 4c 4e 4f putchar-stdout, getchar-stdin, putstring-stdout (9), disk reset (d), ... ah, just found: EGA mode used is E, 640x200x16 ... fcb-close (10), set dta (1a), setintvec, getver (will exit through int 20 if DOS version is 2, otherwise the game is happy with all versions), getintvec, create/truncate file (for save games only I think, 3c), open file (several selectable .bin and .drv, but most files are stored as areas in the 3 main overlay files, and of course save games / configuration: the config tool does not work but the config file luckily is text format...), close file, read file, write file, seek in file (42), alloc ram (48), free ram, exec (used only for mtinit I think), exit, findfirst (4e), findnext. Some code fragments: mov ah,0d int 21 mov dx,... mov ah,10 int 21 jmp ... mov ah,0d int 21 mov dx,... mov ah,10 int 21 stc ret (in the 4k small stick.bin which seems to contain global user interface) mov dx,... mov ah,1a int 21 lds dx,[...] mov cx,dx mov ah,4e int 21 jc ... push cs pop ds les di,[...] add di,201 mov cx,fe push cx push di mov bx,[...] incb [es:bx] mov si,... (then scan 8 chars to copy string up to but excluding the dot) pop di pop cx mov ah,4f int 21 jc ... add di,9 loop ... pop ds ret (in the same stick.bin: find first 254 *.usr save game files) Memory allocation is 256k, once, I think (plus the main file is an exe), and exec only seems to be used once, too (for mtinit). The alloc thing happens in the initial exe, as well as the exec, when the sound, music and graphics drivers are loaded. Then, stick.bin, game.bin and stdply.bin are loaded, too. The latter is probably initial game status, similar to a save game file (which are only 256 bytes each, nice for cheats). Notice that the game is calling findfirst the wrong way: should set AH=4e AL=append flags (0 or non-0) DSDX=pointer CX=attrib mask. But it fails to set AL (will be the low byte of the last pointer to the array of 255 8+1 byte strings which holds the found savegame names), and it sets CX to some more or less random value (the offset of the pointer). I get the PROBLEM that only the volume label is listed in the list of found save games. RBIL tells that this should only happen if CX (I assume only CL is used and bits 0 and 5 are ignored) equals 8. A quick test in DOSEMU tells me that at ((61a)):a16, the mov ah,4e place, CX and DX are both 77a8. And the funny thing is: It WORKS in DOSEMU! However, I tried in a redir-drive in DOSEMU but on a real FAT16 drive in plain FreeDOS. When using a diskimage-drive in DOSEMU, I get the SAME PROBLEM again: Only the label - and because this drive has none, not even that, only the restart game pseudo save game - shows up on the list. So I would like to report a kernel findfirst bug: FreeDOS 2035 treats CX value 77a8 like CX value 0008, and returns only the volume label, for a findfirst for *.usr on a local disk. On a redir disk, no problems happen. Notice that the volume label does not need to be *.usr to show up - it only has to exist - and that the game does not need to be in the root directory to trigger this bug! For now, I can use a patch: replace mov cx,dx by mov cl,0 - but unless FreeDOS accidentally caused the load location 00de (bits 0 and 5 of CX are ignored in findfirst), the CONCLUSION for the kernel should be: ONLY return only the volume label if cx ffde equals 8. Current situation seems to be return only the volume label if cx 00de equals 8. Checking sources... DosFindFirst... network_redirector_fp REM_FINDFIRST... dos_findfirst -- if ((attr (D_VOLID|D_DIR))==D_VOLID) --- this is biased too much towards entering the return only the volume label mode. It should be: First apply some mask - e.g. 00de - to the search attribute, then: if (attr == D_VOLID) ... Notice that dos_findfirst contains TWO lines if ((attr (D_VOLID|D_DIR))==D_VOLID) and one line which already does a similar check as the suggested one: if ((fnp-f_dir.dir_attrib ~(D_RDONLY | D_ARCHIVE)) == D_VOLID fnp-f_dir.dir_name[0] !=
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
[Freedos-kernel] Re: Win3.x /3 investigations, /s ones, cool 386SWAT debugger
Hi Michael, 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. 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 if I do not have data at anyPSP[2c] which makes MSD hang in RAM). When I later switched to SVGA driver and installed SB 1.5 drivers (at least the very old and not feature-rich drivers of Win3.1 - I do not have my SB AWE32 driver CD at hand...), the installer asked me to insert the right floppy, so I did. Actually after the first error I am given the chance to type a directory instead, but inserting the right floppy is easier ;-). Later for actually RUNNING Win3.1 (only /s mode works and DOS sessions do not work) I added a menu entry to my config sys which uses MS HIMEM 3.07 and MS EMM386 4.44 and optionally MS SMARTDRV 4.xx (which I prefer to avoid - and I load it in a way which disables delayed writes, later SMARTDRV versions have delayed writes even disabled by default anyway). But a quick test suggested that even the FreeDOS drivers are no problem. If you have EMM386 loaded, Win 3.1 will attempt to run in 386Enh mode and then fail with unsupported MS DOS (sic!) version, so you must use /s option (order of options matters, if you use the wrong order, the /s is ignored. You must not use the /d:... options for /s mode either...). For FreeDOS EMM386, Win 3.1 will also complain that there is no GEMMIS support (okay, it does not mention the evil word ;-), and it will ask you to use MS EMM386 instead. For /s mode you can even work without any EMM386 at all, but then I cannot use 386SWAT - because for 386SWAT I must first do toggle to other PCI VGA, 'boot' BIOS of that VGA, toggle back, and this (done by a DJGPP-compiled toggler tool and a NASM BIOS loader tool which just loads the, luckily relocateable, BIOS image of the 2nd VGA into DOS RAM, backups IDT and BIOS data area, 'boots' that BIOS (call far...), restores IDT and B.D.A. -- card shows text mode splash screen, BIOS of the other card is compatible enough to handle text mode on both cards) crashes for some unknown reason if I have HIMEM loaded and have no EMM386 loaded. Maybe A20 troubles or something bad which is caught by EMM386 but allowed by HIMEM...? So in short: Everything done with only FreeDOS components and files which were on the 7 3.5inch disks of this original (German) Win3.1 copy here. And working - as far as it works (no 386Enh, no DOS sessions) - without having to use a debugger. I only did use 386SWAT to find out more about how Win 3.1 could be made working together with FreeDOS better than it is already working anyway. Some system.ini excerpts: [boot] 386grabber=vga.3gr ... 286grabber=vgacolor.2gr ... display.drv=supervga.drv mouse.drv=lmouse.drv network.drv= language.dll=langger.dll sound.drv=mmsound.drv comm.drv=comm.drv keyboard.drv=keyboard.drv system.drv=system.drv drivers=mmsystem.dll [386Enh] ... well, I tuned that a lot manually but /3 does not work anyway ... ... what does local=CON mean by the way? [NonWindowsApp] MouseInDosBox=0 ... and DSWAP/WSWAP uses %temp% to swap around sessions, but DOS sessions in /s mode do not work either, so ... CommandEnvSize=512 [drivers] timer=timer.drv midimapper=midimap.drv Wave=sndblst2.drv MIDI=sndblst2.drv MIDI1=msadlib.drv [LogiMouse] Type=Serial Model=C_Series Port=1 DragLock=None [sndblst.drv] port=220 int=5 [display] svgamode=88 ... well, THAT was not selected by me, just using 800x600x256 default ... Eric --- 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
[Freedos-kernel] Win3.1 386Enh patterns (was: More kernel bugs and incompatibilities)
Hi! the code patterns which Windows 3.1 looks for that Eric mentions will NEVER be there, nor should they be there, of course. This depends a lot on WHY the patterns are searched / patched by Win3.1 ... For example the mov ...,dx might be to make something partially relocateable or to trap / buffer some data for partial reentrancy. The mov [...],ds ...,bx is probably similar. No idea yet what the cmp al,7 ...,9 ... is supposed to be, but it involves storing some pointer-ish data at a fixed location. The dx=ax=0 bx=di ds=es call somewhere code is probably to hook that call in question, and the last chunk is again an access to the fixed ss:2ea location, I really wonder what data is stored there. Even if FreeDOS will never contain the code as real code, it could still be added as dummy code which makes Win3.1 look at the right FreeDOS places to hook in some way - or FreeDOS could detect that it is being patched by Win3.1 and enter a more compatible mode then (e.g. start checksumming SFT entries to make sure that SFT and f_nodes stay in sync, or sync segment and stack values in some places if the patches mean that Win3.1 attempts to backup or relocate parts of DOSes state / code / data structures / stack / ... Please refer to the Win3.x /3 investigations, /s ones, cool 386SWAT debugger thread for a detailled description of the pattern matching done by Win3.1 /3. Eric --- 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
