Free dos software for linux

UltimateStunts will be a remake of the famous DOS-game "stunts". This DOS-game, which was released in the early 1990s, can be downloaded on several abandonware sites, e.g. the XTC site .
Ultimate Stunts is a 3D racing game, with simple CGA/EGA/VGA graphics and no texture or smooth shading, but because of the spectacular stunts (loopings, bridges to jump over, etc.) it was really fun to play.
One of the best aspects of this game is that it had a track editor. Because of the tile-based tracks, every gamer was able to make its own tracks.
The remake wont become a DOS game: it will work on UNIX-compatible systems (like Linux), and on windows. It will also provide more modern features, like openGL graphics, 3D sound and internet multiplaying.
The current version is still in a pre-alpha fase, so you shouldnt expect much of it, but the screenshots give a nice impression of how the game will look.
Enhancements:
- Fixed non-functioning online multiplaying function
- Fixed AMD64 compilation bug
- Added abort functionality to loading page

UPX is a versatile executable packer.
Main features:
- excellent compression ratio: typically compresses better than WinZip/zip/gzip, use UPX to decrease the size of your distribution !
- very fast decompression: ~10 MB/sec on an ancient Pentium 133, ~200 MB/sec on an Athlon XP 2000+.
- no memory overhead for your compressed executables because of in-place decompression.
- safe: you can list, test and unpack your executables. Also, a checksum of both the compressed and uncompressed file is maintained internally.
- universal: UPX can pack a number of executable formats:
- atari/tos
- djgpp2/coff
- dos/com
- dos/exe
- dos/sys
- linux/386
- rtm32/pe
- tmt/adam
- watcom/le (supporting DOS4G, PMODE/W, DOS32a and CauseWay)
- win32/pe
- portable: UPX is written in portable endian-neutral C++
- extendable: because of the class layout its very easy to add new executable formats or new compression algorithms
- free: UPX is distributed with full source code under the GNU General Public License, and may be used freely even with commercial programs.

LIBDSK is a library for accessing discs and disc image files. LibDsk is intended for use in:
- Emulator tools - converting between real floppy discs and disc images, as CPCTRANS / PCWTRANS do under DOS.
- Filesystem utilities - CPMTOOLS is configurable to use LIBDSK, thus allowing the use of CPMTOOLS on emulator .DSK images. To do this, install LIBDSK and then build CPMTOOLS, using "./configure --with-libdsk". For CPMTOOLS 1.9 or 2.0, you will also need to apply this patch.
- Emulators - it is possible to use LIBDSK as part of an emulators floppy controller emulation, thus giving the emulator transparent access to .DSK files or real discs.
LIBDSK has drivers for:
- Raw files (including /dev/fdn).
- .DSK files, as used in CPCEMU, JOYCE and other Sinclair/Amstrad emulators.
- MYZ80 hard drive image files.
- NanoWasp floppy image files.
- .CFI (Compressed Floppy Image) files, as created by FDCOPY.COM under DOS.
- The Linux floppy drive (supports CPC System and Data formats, which the standard "Raw file" driver does not).
- The Windows 3.x/95/98/ME/NT/2000 floppy drive.
- The DOS floppy drive (via the PC BIOS).
- CopyQM files (read-only)
- APRIDISK image files
- rcpmfs - a backend that makes a Unix/Windows directory appear to be a CP/M disc image.
- Another instance of LibDsk over a serial line.
Enhancements:
- Two new disc image formats (logical and teledisk) and one new disc geometry (TRDOS 640k) have been added.

PDCurses is a public domain curses library for Win32, DOS, OS/2 and X11, implementing most of the functions available in System V R4 curses. PDCurses for X11 supports most compilers for these platforms.
PDCurses is distributed principally as source code, but pre-compiled libraries are available for various compilers. See the downloads page for a list.
The X11 port of PDCurses, known as XCurses, allows existing text-mode curses programs to be re-compiled and linked with PDCurses to produce a native X11 application.
Enhancements:
- This release adds an SDL backend, refines the demos, and is faster in some cases.

The Plastic File System project is an LD_PRELOAD module for manipulating what the file system looks like for programs. This allows virtual file systems to exist in user space, without kernel hacks or modules.
PlasticFS includes the following file systems:
chroot
The chroot filter may be used to simulate the effects of the chroot(2) system call, in combination with other filters.
dos
The dos filter may be used to simulate an 8.3 DOS file system.
log
The log filter may be used to transparently log file system access, similar to the strace command.
shortname
The shortname filter may be used to simulate file systems with shorter filenames.
smartlink
The smartlink filter may be used to expand environment variables in symbolic links, using the usual $name notation.
upcase, downcase, titlecase and nocase
The upcase filter to make file names appear to be in upper-case when listed. File names are case- insensitive when being opened, etc. The downcase filetr is similar, except it converts to lower-case, titlecase capitalizes, and nocase is simply case insensitive without altering the filenames.
viewpath
The viewpath filter may be used to make a set of directory trees look like a single directory tree. (Also known as a union file system.) All modifications take place in the first directory in the list.
Aka: union and translucent
Note: Filters may be piped from one to the next, forming powerful combinations.
PlasticFS is currently dependent on the implementation of the GNU C Library. It is self configuring using a GNU Autoconf generated configure script.
Enhancements:
- Build problem fixed.

MGRX project is a 2D graphics library derived from the GRX library. GRX was originaly written by Csaba Biegl for DJ Delories DOS port of the GCC compiler. MGRX supports four platforms: DOS (DJGPPv2), Linux console, Linux X11 and Win32 (Mingw). On DOS it supports VGA and VESA compliant cards. On Linux console it uses the framebuffer. On X11 and Win32 it runs in a window.

Why MGRX

MGRX is a fork of GRX. Because I liked the GRX C API interface, I began to maintain GRX when it was orphaned at the end of 2000. But GRX has not only the C API, it has a Pascal API, a BGI compatibility API, support for Turbo C, Wattcom, MSC and some X11 implementations over mainframes. At the end it was not funny, to easy to break things I dont know (and dont want to know). So I stoped my job maintainig GRX at the end of 2003. At the time I write this, GRX is still orphaned.

But in the mean time I developed a fork for my own use, only the C API, no Pascal, no BGI, no Turbo C support, only the 4 platforms I can test. And a new (and better I think) input API. And now I have released it, only for fun.

Supported platforms:

Latest versions of OS, compiler, and key software tested:
Linux X11: linux 2.6.18, Xorg 7.2, gcc 4.1.2
Linux fb: linux 2.6.18, gcc 4.1.2
DJGPP: djdev 2.03, gcc 4.1.2
Win32: Windows XP, MinGW 3.1.0-1

whouses Perl module is an impact analysis in a clearmake build environment.

SYNOPSIS

Run this script with the -help option for usage details. Here are some additional sample usages with explanations:

whouses foobar.h

Shows all DOs that make use of any file matching /foobar.h/.

whouses -recurse foobar.h

Same as above but follows the chain of derived files recursively.

whouses -exact foobar.h

Shows all DOs that make use of the specified file. The -exact flag suppresses pattern matching and shows only DOs which reference the exact file.

Whouses provides a limited form of "impact analysis" in a clearmake build environment. This is different from traditional impact analysis (see TRUE CODE ANALYSIS COMPARED below for details). In particular, it operates at the granularity of files rather than language elements.

Whouses is best described by example. Imagine you have a VOB /vobs_sw in which you build the incredibly simple application foo from foo.c. You have a Makefile which compiles foo.c to foo.o and then links it to produce foo. And lets further assume youve just done a build using clearmake.

Thus, foo is a derived object (DO) which has a config record (CR) showing how it was made. Whouses analyzes that CR and prints the data in easy-to-read indented textual format. For instance:

% whouses -do foo foo.c
/vobs_sw/src/foo.c =>
/vobs_sw/src/foo.o

The -do foo points to the derived object from which to extract and analyze the CR; it will be implicit in the remaining examples. The output indicates that foo.o uses foo.c, or in other words that foo.c is a contributor to foo.o. If we add the -recurse flag:

% whouses -r foo.c
/vobs_sw/src/foo.c =>
/vobs_sw/src/foo.o
/vobs_sw/src/foo

We see all files to which foo.c contributes, indented according to how many generations removed they are. If we now add -terminals

% whouses -r -t foo.c
/vobs_sw/src/foo.c =>
/vobs_sw/src/foo

Intermediate targets such as foo.o are suppressed so we see only the "final" targets descended from foo.c.

We can also go in the other direction using -backward:

% whouses -b -e foo
/vobs_sw/src/foo<<less