https://en.wikipedia.org/wiki/Runtime_library ... so yes, pretty important.

[EDIT:] P.S I should say its nothing to worry about. Pretty much all MS-DOS programs will have that (or something similar for another MS run-time library).

[EDIT:EDIT:] Out of curiosity, You're using a HEX editor to examine the files? What's the end goal you are trying to achieve here? I only ask because if you asking what a run-time library is, you have a hell of a learining curve coming up o.0.

The executables you've been noticing were probably compiled with Microsoft C. Runtime library code exists in executables produced by most programming languages, even today. Assembly language tends to be an exception, although library code of some sort can be used there too. However, relatively few DOS games were/are programmed exclusively in assembly.

Hi,

First of, thanks for the answers so far. I see I really need to phrase my questions better and provide more information. So to clear a few things up:
1. I know what a run-time library is and am not worried about its presence in those games.
2. That the library I'm referring to would be written in C is my guess too.
3. My end goal (if it's even remotely possible) is to find out more about the run-time libraries specifically used by those games and what it's being used for. Probably stuff such as file access and memory management...
4. I'm using the Microsoft Editor in DOSBox on Windows 7 64bit to view these files, I simply use the "Open Binary" option.

BTW:
I've some experience with assembly language and disassembling stuff, but I do most things with vb.net. (Used to be Quick Basic and Visual Basic classic.)

Yes, runtime code is for things like file access, memory management, device I/O, etc. Compilers typically convert the logic of the compiled program into a branching machine code structure that contains calls to library functions at points.

I don't know how much info you can get from the executable binary unless you're searching for something really specific, but in addition to Microsoft C other popular C compilers of the time were Borland Turbo C or Watcom C, so you may also find references to those in other executables, depending on what was used to compile them.

Normally the libraries were statically linked to the executable, but I don't remember how much support (if any) there was for dynamic linking in DOS with those compilers.

Turbo Pascal was wildly popular for the longest time, and it is a bug in the Pascal libraries (specifically the "CRT unit") that resulted in the infamous Runtime Error 200 bug that prevents such programs from running on fast CPUs. The programs are usually easily patched because they generally contain a recognizable hex string in which a few problematic bytes may be changed.

Information on the problem abounds.
http://www.pcmicro.com/elebbs/faq/rte200.html

Jorpho wrote:

Turbo Pascal was wildly popular for the longest time, and it is a bug in the Pascal libraries (specifically the "CRT unit") that resulted in the infamous Runtime Error 200 bug that prevents such programs from running on fast CPUs. The programs are usually easily patched because they generally contain a recognizable hex string in which a few problematic bytes may be changed.

Information on the problem abounds.
http://www.pcmicro.com/elebbs/faq/rte200.html

Does this work for Jazz Jackrabbit?

In the case of Jazz Jackrabbit, I recall that you have to patch FILE0001.EXE instead of (or maybe in addition to?) JAZZ.EXE. I'm pretty sure I saw that documented in a big list of fixes not so long ago.

Other problems arise when the executable is compressed by an .exe packer (i.e. which auto-decompresses into RAM only when it is run).

Some files contain the error message "Packed file corrupt.". I assume this means that the executable is compressed in some way. Unlzexe.exe and dislite.exe appear to be unable to decompress these files. Does any one here know of other decompression utilities for MS-DOS executables?

UNP can decompress many types of DOS executable compression, although there are a few unusual ones it does not. The "Packed File Corrupt" message is from EXEPACK, an RLE compression utility included with Microsoft programming languages.

ripsaw8080 wrote:

UNP can decompress many types of DOS executable compression, although there are a few unusual ones it does not. The "Packed File Corrupt" message is from EXEPACK, an RLE compression utility included with Microsoft programming languages.

Unrelated but you have the best avatar. Yeti FTW

Is this it: http://www.shikadi.net/moddingwiki/Microsoft_EXEPACK?

EDIT:
I found this useful utility: http://unp.bencastricum.nl/