A lot of work has been done since 0.63.
DOSBox SVN Builds
Maybe your problems have also been fixed.

The fpu is emulated using double-precision in dosbox 0.63, which CAN
result in odd results like 3/2=2, especially when it comes to the output
conversion of some compiler libraries.
The next version uses an 80 bit precise fpu emulation on x86 systems,
so you should try a newer version as HAL said.

Thanks! I'll try CVS-Compile/AEP-EMU version. Unfortunately, the web site appears to be down at the moment.

There is a huge amount of valuable work that was done in DOS for scientific & engineering problems. I even know one guy who still sells a specialized CAD package that only runs in DOS. I know a lot of DOSBox development is for games, but it could also save a lot of other software from the dustbin. Thanks to everyone for supporting this effort.

Well there's nothing stopping a person from using the DosBox CVS however they want. As long as they follow the requirements of GPL.

Well, I downloaded the latest CVS compile, and it works better in many ways, but it's still returning integers for all calculations. I'm at a bit of a loss for what to do next, but I will be happy to work with anyone who understands the inner workings to try to chase this down.

In the meantime, I'm really excited about DOSBox. It's showing enormous promise for a bunch of long standing problems I've had with running DOS apps under Windows. I've got another application at work that I will try it on tomorrow.

Thank you!

More likely something with those bin2dec/asc opcodes than
the fpu, maybe you can upload samples (like non-copyrighted
executables) that show the problem.

Because the application is actually a programming environment, I can create a small executable that will demonstrate the problem. I'll rig it up to run a sample set of calculations with a copy of the correct answers on-screen I'll park it on my website and post a link to it on Monday.

Thanks!

OK, here's a test program that will re-create the problem at will:

http://users.rcn.com/gwhite/APL/DBOXTEST.zip

It works fine if run directly in XP, both on a Dell system and an IBM laptop, but it
produces only integer results in DOSBox.

I also discovered today that a previous version of the APL interpreter seems to work OK in this regard. I have no idea why something so fundamental would change between successive versions.

I can create quite a wide range of test programs using the "run time interpreter" APL system, and I'm hoping this approach will help with the debugging process. If anyone needs more info on exactly how this program was created, let me know.

Thanks!

They need the fpu precision exception bit in their
floating output routines. It is ignored because of
speed reasons, but you can enable it by out-commenting
the line
#define WEAK_EXCEPTIONS
at top of fpu_instructions_x86.h

You can try some CVS build from around last december,
there this option was always configured to provide the
maximal possible fpu exception flags.

Thanks! That was quick. I'll have to look into an older CVS build, or getting set up to compile the source myself. The last time I worked with a compiler was about 20 years ago, so I'm a bit rusty.

In the meantime, I'd like to suggest that a config file switchbe installed for this in future releases. I can certainly get set up to compile my own custom versions. However, I've already found a couple other minor bugs, and it will be hard for folks to investigate them if they have to have a custom compiled version to run the executables I can create.

If this is either A) a pain in the neck, or B) not worth the bother compared to other work, I can muddle along. The older interpreter that doesn't have the integer problem won't create executables, but I think can rig up something. It will just be a bit more work to install if someone wants to run something to duplicate any problems I find.

I have a very large suite of test routines for my APL software, which is a microwave circuit analysis tool. Now that this issue is somewhat resolved, I can start trying to run those and see what happens. When DOSBox can pass all those tests without any hiccups, it will be pretty bulletproof.

Thanks again for your help!

Hm, i don't think this'll be made switchable, please keep in mind that
the goal of dosbox are dos games. I think ykhwong has some older
builds on his homepage, so you don't need to build it yourself.

Maybe your compiler suit has an option to not rely on fpu exception
flags, or ignore fpu exceptions, so it should behave like your old compiler.

I'll check out ykhwong's archives. I realize that the primary thrust is to support old games, but I'd be surprised if there isn't one or two out there that would run afoul of this as well. I don't know if there is a downside to using a switch. I suppose the compiled code will be more compact if it's left out. In any event, I figured it never hurts to ask. Besides, if you knew how much fun it is to program in APL, you'd think it was a game too. 😀

The problem with the app I'm running is that it isn't compiled. I'm using commercial APL interpreters that I don't have the source code to. The code I'm running is written in APL, and then run in the interpreter environment. The executable test program was produced with a "run-time interpreter" that bundles the APL code and the interpreter into a tidy package. Most of the time folks work directly in the interpreter. The run-time trick is just if you have a small routine you want to pass along to folks who don't have the interpreter and/or aren't familiar with APL.

I compiled an up to date CVS (as up to date as anonymous CVS can be 😀) with the change wd wrote above.
You can get it at (link deleted now - file was received 😀)
Please pm when you have downloaded it, I can't provide it for everyone 😀
Hope it helps, so you know it's just this little change.
When (hopefully soon) the new version of Dosbox is released I can make a built of the release source for you as well with the above change.

If it works and you end up using Dosbox for all this, you may consider a donation to the Dosbox team http://sourceforge.net/project/project_donati … ?group_id=52551
I don't know what they do with the money but I think it is a nice gesture when you use it in a commercial field. (This is just my opinion and I'm not part of the Dosbox team, so don't hold my speech against them 😀)

Many thanks to both Dominus and to wd! I downloaded the CVS Dominus compiled and it works like a champ! wd nailed it. You guys rock!

Now I can get to back testing & hunting for more bugs...

I'm running the ancient Pocket APL using the OS X DOSBox on an Intel MacBook, and I'm having a similar problem: Functions show up as variables, they fail to execute, etc.

Pocket APL ran fine under Virtual PC, but has graphics issues under Parallels and VMWare Fusion. DOSBox seems to get the closest, but Pocket APL is only sort of half-working. Would a more recent (or tweaked) build solve my problem?

Thanks...

-- Jeff

Would a more recent (or tweaked) build solve my problem?

No because exception flags are not supported on macos as the emulation
is done in highlevel language.

Maybe this is a very dumb idea, as I don't have a Mac myself (well except for an ancient 68k monster). But couldn't you run the Windows version of DOSBox under Parallels or some other tool that allows you to run Windows software?

--
Linards Ticmanis

If parallels passes the fpu stuff fine, it should work (you'll need to set
core=dynamic in the dosbox.conf for the 0.72 release).

Argh. Setting core=dynamic didn't help.

It's weird: the only Mac emulators which have ever run Pocket APL correctly are SoftWindows (remember that?) and Virtual PC. Both VMWare Fusion and Parallels have graphics issues, and DOSBox has the odd glitches described above.

Anyone who comes up with a fix gets an autographed 8x10 of the Desperate Housewives cast. I'm not kidding.

-- Jeff