Just for fun, I threw together GENEVL.C which create EVL.BAT:

1@echo OFF
2%1 %2 %3 %4 %5 %6 %7 %8 %9
3echo 0
4if errorlevel 1 echo 1
5... repeat for 2-254 ...
6if errorlevel 255 echo 255

Here is a test run:

1R:\> EVL ERRLVL 5
2Exit[5]           <- produced by ERRLVL
30
41
52
63
74
85
9R:\>

Attached .ZIP contains GENEVL.C and the generated EVL.BAT

Hello, I tried two of the tools mentioned in the thread. For some reason, DaveDDS's errlevel tool crashes dosbox and igully's errlevel tool shows this screen after running:

Thank you all again for the information and tools provided. If there is something I'm doing wrong or that I'm missing, please let me know

I apologize, I hadn't seen davedds's most recent post. I tried genevl and it seems to have worked perfectly while the other tools for some reason didn't.

Cursed Derp wrote on Yesterday, 20:31:

Hello, I tried two of the tools mentioned in the thread. For some reason, DaveDDS's errlevel tool crashes dosbox and igully's errlevel tool shows this screen after running:w

My tool is called ERRLVL.COM - you are running ERRLEVEL - I think it was posted by someone else, and I've not looked at.

It looks like you are .BAT file of some sort, with commands DOS doesn't recognize in it.

ERRLVL.COM is an executable program which searches for a .COM or .EXE in current directory, then along your path and executes it directly (not via DOS command processor) - this allows it to receive the actual exit code the program terminated with. No batch is involved.

I assure you it works find in DosBox - I use it frequently there.

The problem is that you are running DOSBOX not a real DOS.
It works on a real DOS, like MS-DOS, DR-DOS, PC-DOS, etc.

It is likely that the emulation/simulation of DOSBOX DOS batch file processing API is not complete or accurate.

igully wrote on Today, 01:25:

The problem is that you are running DOSBOX not a real DOS.
It works on a real DOS, like MS-DOS, DR-DOS, PC-DOS, etc.

It is likely that the emulation/simulation of DOSBOX DOS batch file processing API is not complete or accurate.

I'm curious - have you tested this in older versions of DOS?

I've not looked at the script other than the error messages that were posted - I do seem to recall that .BAT file capability was less in oldere versions (but it has been a long time since I looked closely)

Fwiw: ERRLVL.COM works in DosBox (that's probably where I use it most often)

That's a windows DOS batch file. It definitely will not run on DR-DOS, PC-DOS, etc.

It works under MS-DOS 6.22, PC-DOS 6.3, and DR-DOS 7.01.

Lots of things fail on DOSBOX and also it has its own set of inaccuracies. It is extremely easy to set up, which is its most favorable aspect. I do however, prefer PC emulators which are precise and accurate at what they do (with the added complexity to set them up).

You know DOSBox can run MS-DOS, right? Just like those other emulators.

jmarsh wrote on Today, 03:36:

You know DOSBox can run MS-DOS, right? Just like those other emulators.

Other emulators run DOS. I have just submitted three pictures taken on VirtualBox a minute ago with DOSes I had at hand, but could well have used 86Box or the other emulators of the lot.

I guess you're unaware DOSBox can boot disk images just like those other emulators. In which case it won't be using its own shell, and can run batch files that contain commands only compatible with "windows" DOS.

I am aware. But again, it is not a precise emulator/simulator/virtual environment. It is easy to set up but it is not precise at all because it uses shortcuts to achieve faster speeds.

For example, it has troubles handling code that changes on the fly.

igully wrote on Today, 04:07:

I am aware. But again, it is not a precise emulator/simulator/virtual environment. It is easy to set up but it is not precise at all because it uses shortcuts to achieve faster speeds.

For example, it has troubles handling code that changes on the fly.

No it doesn't - the interpreter core looks at each opcode byte as it is executed so there's no assumptions there, and the dynamic core can detect when code memory is changed and either recompile it or flag it as "volatile". Maybe you'd like to give an example rather than just post AI generated responses?

Regardless this has no bearing on DOSBox's ability to run "real" DOS, even the versions that are designed for windows compatibility.

There is nothing AI generated in every post I write.

Here you have an example of a couple of months ago:
Emu386 - 386 emulator for 286

Look at how DOSBOX confuses an 80188 and an 80186, which both have a different prefetch queue.

igully wrote on Today, 04:20:

Here you have an example of a couple of months ago:
Emu386 - 386 emulator for 286

Look at how DOSBOX confuses an 80188 and an 80186, which both have a different prefetch queue.

DOSBox doesn't emulate either of those CPU types. You're talking about DOSBOX-X which uses completely different emulation at this point.

I don't care any nuances. I prefer precise emulation. And this is already going off into a tangent.
You do you for whatever reason fits you. It is still a free world, in some places...

Tangents indeed, since OP's specific question was:

So is there a way in dosbox to use a batch file to find the error level number of an error?

igully wrote on Today, 03:34:

... Lots of things fail on DOSBOX and also it has its own set of inaccuracies. It is extremely easy to set up, which is its most favorable aspect ...

I agree completely that DosBox isn't "perfect" ... but in most cases I find it good enough.

I guess I'm a bit different from most in that I mostly use tools I've personally written over the years (I tend not to do "weird" things in my code and almost everything has run perfectly under DosBox with no changes).

- Then again, with a simple re-compile, a lot of it runs without other changes on my own DVM (Dunfield Virtual Machine) which is a tiny VM that also allows host-native file access, and doesn't emulate any x86 - it uses my own "C-FLEA", a CPU I designed to be an optimal target for my compiler (a whopping 200 lines of 'C' with NO library calls - and faster than any x86 VM I've tested) and incorporates a "special" DOS function opcode and emulates enough of DOS to satisfy most of my library. This lets me run the same tools under DOS, Windows, Linux and any other OS I want to port it to.

--

But... I disagree that "easy setup" is DosBoxs "most favorable aspect".

What I like most about DosBox, "far and above" other emulations (which I do use frequently) are:

- Ability to locally mount host directories as "drives" for direct access without having to setup a DOS network compatible with modern hosts.

- Very low DOS memory footprint (lots of conventional RAM avalable)

-Ability to boot "real" DOS from disk images, with ability to re-configure how those disks (and the boot environment) appears "on the fly" (ie: under program control)
(I've got a test environment set up where I can boot 17 different versions of real-DOS just by pickinf the one I want from a startup menu. Even though some of the oldest versions have to boot from 160l, 320k or 360k floppy disk images)