Did a few more experiments: I think the problem is the OpenWatcom DOS4gw. I can't compile with either OpenWatcom C or OpenWatcom FORTRAN (but I can compile fine with Turbo C). I get a stack trace but it was late and I needed to go to bed so I didn't capture it. I also tried booting without fdconfig.sys or fdauto.bat.
I'll try a few more experiments tomorrow afternoon. My plan: 1. Reinstall with 1.3 and try again (if the error happens there too, at least this isn't a regression, and it's more likely to be an issue with the missing math coprocessor) 2. Reinstall with 1.4 and try again Any other experiments I should try? My FORTRAN program is just a simple "hello world" program, plus another one that just counts 1 to 10. There's nothing tricky here. Same for the sample C programs. On Tue, Apr 1, 2025, 6:20 PM Jim Hall <jh...@freedos.org> wrote: > It would be great for others to test this too. I'll also try it again and > see if it was just a poorly timed hang—the battery died shortly afterwards, > so could be something with that, but I doubt it. > > I am not too concerned about this one issue because: > > 1. It works on QEMU, and I'm sure works on other systems with a math > coprocessor > > 2. I don't think the FORTRAN compiler changed since 1.3, so it's unlikely > to be a regression > > 3. I've experienced other programs that have barfed on the Pocket386 > (exited with a crash, no "this requires a math coprocessor") so this is not > isolated, but unfortunate if true > > On Tue, Apr 1, 2025, 5:25 PM Bret Johnson <bretj...@juno.com> wrote: > >> > My only issue is that the OpenWatcom FORTRAN 77 compiler isn't able to >> > compile programs on the Pocket386 laptop. But OpenWatcom F77 works >> > fine on QEMU, so this is something to do with the Pocket386's 386-SX >> > CPU, which doesn't have a math coprocessor. >> >> That could well be the problem, but it needs a little more testing to >> verify. >> >> If a program _requires_ a coprocessor to run and the computer doesn't >> have one, the program should quit with an error message indicating that >> right away. I also know there were libraries available in various >> languages to simulate a coprocessor if a physical one wasn't available, >> though things generally run _much_ slower than with a real one. I would >> think a compiler would have something like that built into it, and would >> also automatically embed it into any programs it compiled if they also >> required a coprocessor. >> >
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
