Re: [Freedos-user] Two non-bug reports.
Hi, 2009/7/4 Christian Masloch : >> First non-bug: LFN-EN utilities don't work with my FAT32 partition >> under FreeDOS. >> >> After examining the source code, it turns out that the logic was coded >> in 1999 when >> the only DOS that could handle FAT32 was MS-DOS. When run under >> FreeDOS, the utilities >> assume no FAT32 support, so they misidentify the partition as FAT12. >> >> For test purposes, I made a version that accepted the vendor byte FD >> (FreeDOS) instead of >> FF (MS-DOS) and it worked, but anything used in production would have to >> use a different >> method to determine whether FAT32 is supported (FreeDOS comes both ways, >> and there are several DOSses today that support FAT32.) >> >> There is similar logic that determines which versions of DOS require >> volume locking >> (MS-DOS 7 or later.) >> >> Fortunately the LFN-EN utilities are open source, so someone could fix >> this. > > A reliable FAT32 test method is to check whether a common subfunction of > Interrupt 21h, Function 73h (FAT32 extensions) is supported. I disregard > any method that works per DOS version. Users apparently don't want > technical details on the Freedos-user list however. > I don't think so: some want, some do not. The question is that currently there's no way to know about it. So I am almost decided to create that freedos-basic list, so that technical details can run here as usual. Cheers, Aitor -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] buggy djgpp with freedos.
Maybe someone can figure this one: installed freedos base on an old dell(ten years);installed djgpp with rhide; acted very buggy and refused to compile even a hello world; rebooted with 'himem' option, and now it compiles and executes. However, I then tried a larger program with eight functions, and it too, compiled and 'created' with no problems. Tried to run the executable and got this: page fault at 0x1ba1;error 0006; I'm sure that the program partially executed since the mouse cursor was left on the screen, and my program involves a mouse event handler. The program involves calls to 'int86', but this should not crash anything, since even the NT dosbox allows this. Was I deluded all this time into thinking djgpp was 'backward compatible' with a true dos system, and I just never strained the high memory aspect until now? --kurt. -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Minor nit: Norton Utilities slow with FDAPM APMDOS; FDAPM APMOFF fixes.
> Norton Text Search (ts.exe) prints about four characters a second when > FDAPM APMDOS is running. Setting FDAPM APMOFF fixes this. This may > also affect other Norton Utilities. > > I suspect it's because FDAPM hooks an interrupt for power saving use > that Norton was already using for something. Try FDAPM APMBIOS. Does it still affect the program's performance? APMDOS hooks too many interrupts. Regards, Christian -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Two non-bug reports.
> First non-bug: LFN-EN utilities don't work with my FAT32 partition > under FreeDOS. > > After examining the source code, it turns out that the logic was coded > in 1999 when > the only DOS that could handle FAT32 was MS-DOS. When run under > FreeDOS, the utilities > assume no FAT32 support, so they misidentify the partition as FAT12. > > For test purposes, I made a version that accepted the vendor byte FD > (FreeDOS) instead of > FF (MS-DOS) and it worked, but anything used in production would have to > use a different > method to determine whether FAT32 is supported (FreeDOS comes both ways, > and there are several DOSses today that support FAT32.) > > There is similar logic that determines which versions of DOS require > volume locking > (MS-DOS 7 or later.) > > Fortunately the LFN-EN utilities are open source, so someone could fix > this. A reliable FAT32 test method is to check whether a common subfunction of Interrupt 21h, Function 73h (FAT32 extensions) is supported. I disregard any method that works per DOS version. Users apparently don't want technical details on the Freedos-user list however. Regards, Christian -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Could the MDADEBUG TSR be used to find this FreeCOM bug?
On Fri, Jul 3, 2009 at 4:34 PM, Shane Baggs wrote: > I've posted before about the four machines I'm running FreeDOS on -- One is > exceptionally well behaved with FreeDOS 1.0 and another is exceptionally > quirky. In particular, I've been experiencing the FreeCOM bug where the > command prompt returns without executing the command. Nobody knows for sure > when this happens, but it seems to happen in response to a general > protection fault that goes unreported, as 4DOS reports a general protection > fault under the same conditions. > > I just discovered MDADEBUG, available from Marc Alexander's page > http://www.onr.com/user/mda > It's a debugger as a TSR. > > I've got a machine where the bug can be triggered on a fairly regular basis. > I've been able to trigger the bug, then press ctrl/alt/F12 and get the > debugger. > Now that I've got the bug and the debugger, what should I look for? It's probably a good idea to use the debugger to log what calls to int 0x21 occur between calling a command and the next prompt that occurs. We want to know exactly what FreeCOM is doing so that we can hopefully find out what is happening differently than in a normal instance. > > > > Lauren found her dream laptop. Find the PC that’s right for you. > -- > > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > > -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
