New upstream version 2.0pre9.2
Some checks failed
Master / Scheduled (FULL) (push) Has been cancelled
Master / Triggered (push) Has been cancelled
Master / Triggered (ASAN) (push) Has been cancelled
Master / Triggered (FULL) (push) Has been cancelled

This commit is contained in:
geos_one
2025-08-10 12:35:43 +02:00
commit 91736529d5
1056 changed files with 370820 additions and 0 deletions

607
doc/EMUfailure.html Normal file
View File

@@ -0,0 +1,607 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Known dosemu problems</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"></HEAD
><BODY
CLASS="ARTICLE"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="ARTICLE"
><DIV
CLASS="TITLEPAGE"
><H1
CLASS="TITLE"
><A
NAME="AEN2"
>Known dosemu problems</A
></H1
><DIV
><DIV
CLASS="ABSTRACT"
><P
></P
><A
NAME="AEN4"
></A
><P
>This file lists programs and groups of programs not running or running
only partially under dosemu. The most up-to-date version of this file
may be found on:
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
><A
HREF="http://www.dosemu.org/"
TARGET="_top"
>http://www.dosemu.org/</A
></I
></SPAN
>.
Please report about possible additions to
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
><A
HREF="mailto:linux-msdos@vger.kernel.org"
TARGET="_top"
>linux-msdos@vger.kernel.org</A
></I
></SPAN
>
or the SourceForge BTS at
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
><A
HREF="http://www.dosemu.org/"
TARGET="_top"
>http://www.dosemu.org/</A
></I
></SPAN
>.
Perhaps your program can be made going
with the help of others. Have a look at the dosemu-howto how to do so.</P
><P
></P
></DIV
></DIV
><HR></DIV
><DIV
CLASS="TOC"
><DL
><DT
><B
>Table of Contents</B
></DT
><DT
>1. <A
HREF="#AEN12"
>Fundamental problems</A
></DT
><DD
><DL
><DT
>1.1. <A
HREF="#AEN15"
>Virtual Control Program Interface (VCPI)</A
></DT
><DT
>1.2. <A
HREF="#AEN19"
>Programs using older versions of the Pharlap Extender</A
></DT
><DT
>1.3. <A
HREF="#AEN24"
>Programs using the JEMM memory manager</A
></DT
><DT
>1.4. <A
HREF="#AEN28"
>Does my failing program belong to these groups?</A
></DT
><DT
>1.5. <A
HREF="#AEN32"
>Fundamental problem with the Linux kernel</A
></DT
><DT
>1.6. <A
HREF="#AEN40"
>Fundamental problems with the CPU</A
></DT
><DD
><DL
><DT
>1.6.1. <A
HREF="#AEN43"
>Problem with the virtualization of the IF flag</A
></DT
><DT
>1.6.2. <A
HREF="#AEN52"
>ESP register corruption</A
></DT
></DL
></DD
></DL
></DD
><DT
>2. <A
HREF="#AEN69"
>Known bugs</A
></DT
><DD
><DL
><DT
>2.1. <A
HREF="#AEN71"
>Things YOU may help changing</A
></DT
><DD
><DL
><DT
>2.1.1. <A
HREF="#AEN73"
>List of currently known bugs in dosemu2</A
></DT
></DL
></DD
></DL
></DD
><DT
>3. <A
HREF="#AEN84"
>Programs exhibiting graphical problems in xdosemu</A
></DT
><DD
><DL
><DT
>3.1. <A
HREF="#AEN87"
>Games with graphical problems</A
></DT
></DL
></DD
><DT
>4. <A
HREF="#AEN95"
>Differences in behaviour between Dosemu and Dosemu2</A
></DT
><DD
><DL
><DT
>4.1. <A
HREF="#AEN98"
>Filesystems</A
></DT
><DD
><DL
><DT
>4.1.1. <A
HREF="#AEN100"
>MFS</A
></DT
></DL
></DD
></DL
></DD
></DL
></DIV
><DIV
CLASS="SECT1"
><H2
CLASS="SECT1"
><A
NAME="AEN12"
>1. Fundamental problems</A
></H2
><P
>Programs that don't work under the MSDOS Emulator and probably won't
ever work, because of fundamental problems. Some of these fundamental
problems result in these programs not being runnable on
Win3.x/Win95/WinNT and under OS/2 DOS box either. These programs
are characterized by using any of these features:</P
><DIV
CLASS="SECT2"
><HR><H3
CLASS="SECT2"
><A
NAME="AEN15"
>1.1. Virtual Control Program Interface (VCPI)</A
></H3
><P
>VCPI allows programs to run in ring 0. This is kernel mode in Linux
and not sensible.</P
><P
>Example: sim2181.exe from Analog Devices DSP Kit</P
></DIV
><DIV
CLASS="SECT2"
><HR><H3
CLASS="SECT2"
><A
NAME="AEN19"
>1.2. Programs using older versions of the Pharlap Extender</A
></H3
><P
>Older versions of the Pharlap Extender (run286) need ring-0 access
under DOSEMU to install their own DPMI server. The use of proprietary
undocumented extensions to the DPMI protocol makes DOSEMU's DPMI server
unsuitable for this extender.</P
><P
>Example: Autocad Version 12c1 For DOS</P
><P
>Example: the game BioForge by Origin Systems.</P
></DIV
><DIV
CLASS="SECT2"
><HR><H3
CLASS="SECT2"
><A
NAME="AEN24"
>1.3. Programs using the JEMM memory manager</A
></H3
><P
>The JEMM memory manager provides proprietary extensions to the EMS
protocol. These are not supported by DOSEMU.</P
><P
>Example: Wing Commander Privateer by Origin Systems</P
></DIV
><DIV
CLASS="SECT2"
><HR><H3
CLASS="SECT2"
><A
NAME="AEN28"
>1.4. Does my failing program belong to these groups?</A
></H3
><P
>Check with "strings &lt;program.exe&gt; | less" if the program
contains some of these keywords: <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
> vcpi, RUN286</I
></SPAN
>.</P
></DIV
><DIV
CLASS="SECT2"
><HR><H3
CLASS="SECT2"
><A
NAME="AEN32"
>1.5. Fundamental problem with the Linux kernel</A
></H3
><P
>The Programmable Interval Timer (PIT) can be programmed to produce
interrupts with frequencies up to almost 2MHz. Linux sets this to
only 100Hz (2.6 kernels can set it to 1KHz) and doesn't allow the
software to change that. This limits the minimal interval between subsequent
SIGALRM notifications for software that uses the setitimer(2) syscall.
To emulate the PIT frequencies that are higher than the frequency Linux
sets the PIT to, dosemu uses "interrupt bursts": on every SIGALRM
reception dosemu triggers the timer interrupt as many times as necessary
to compensate the gap since the previous SIGALRM reception. This allows
to keep a precise timing but causes problems for some programs. When
the timer interrupt handler is invoked more than once without letting
the main thread to execute, some programs can lock up. The game "Cosmo" is
one of those.</P
><P
>Another problem is that due to the aforementioned low timer frequency
dosemu is not able to properly emulate the timings for different
emulated hardware. That also causes problems for some programs.
Scream Tracker 3, for example, can lock up at startup because the
interrupt from an emulated SB card can be triggered earlier than it
should be in a real system.</P
><P
>Possibly a workaround may be found in future DOSEMU versions.</P
><P
>Linux kernels prior to 3.16 may have various problems on x86-64.
Make sure to not use 3.14 and 3.15 as they
<A
HREF="https://www.codeweavers.com/support/wiki/Diag/BrokenLDT16"
TARGET="_top"
>lack 16bit segments support</A
></P
><P
>3.16 adds support for espfix64 feature.</P
></DIV
><DIV
CLASS="SECT2"
><HR><H3
CLASS="SECT2"
><A
NAME="AEN40"
>1.6. Fundamental problems with the CPU</A
></H3
><P
>There are several defects in Intel's x86 CPUs that are causing
problems for some software. Below is a description of the defects
that are known to cause problems for software running under dosemu.</P
><DIV
CLASS="SECT3"
><HR><H4
CLASS="SECT3"
><A
NAME="AEN43"
>1.6.1. Problem with the virtualization of the IF flag</A
></H4
><P
><A
HREF="http://www.intel.com/design/intarch/techinfo/pentium/inout.htm"
TARGET="_top"
>Intel's manual</A
>
says:</P
><P
>" A procedure may use the POPF instruction to change the setting of the IF
flag only if the CPL is less than or equal to the current IOPL. An attempt
by a less privileged procedure to change the IF flag does not result in
an exception; the IF flag simply remains unchanged. "</P
><P
>The fact that the exception is not being generated, prevents dosemu from
catching and properly simulating the POPF instruction executed in protected
mode. That, in particular, means that the following code, executed in
protected mode (not in v86 mode) under dosemu, will end up with interrupts
disabled (IF cleared):</P
><P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
> sti
pushf
cli
popf</PRE
></TD
></TR
></TABLE
>
[ the interrupts are still disabled here ]</P
><P
>This bug can only affect DPMI programs, as using DPMI is the only way
to execute protected mode code under dosemu.
Known programs that are affected are the games from ID software, namely
Doom2 and Duke Nukem 3D, but only when configured with sound.
An optional work-around was added to dosemu, which just re-enables the
interrupts if they were disabled for too long in protected mode.
Additionally the address of the instruction that disabled the interrupts,
is added to a black-list and this instruction is ignored for subsequent
passes so that it can't disable the interrupts any more.
This is potentially unsafe, but if the timeout is long enough, no harm
was observed so far.
The timeout is configured via the $_cli_timeout option, which is measured
in a 10ms timer ticks. Setting that option to 0 disables the workaround
completely, making Doom2 unplayable with sound enabled.</P
></DIV
><DIV
CLASS="SECT3"
><HR><H4
CLASS="SECT3"
><A
NAME="AEN52"
>1.6.2. ESP register corruption</A
></H4
><P
>Intel's x86 CPUs have a defect
<A
HREF="http://www.intel.com/design/intarch/specupdt/27287402.PDF"
TARGET="_top"
>described here</A
>,
chapter "Specification Clarifications"
section 4: "Use Of ESP In 16-Bit Code With 32-Bit Interrupt Handlers",
which reads as follows:</P
><P
>"ISSUE: When a 32-bit IRET is used to return to another privilege level,
and the old level uses a 4G stack (D/B bit in the segment register = 1),
while the new level uses a 64k stack (D/B bit = 0), then only the
lower word of ESP is updated. The upper word remains unchanged. This is
fine for pure 16-bit code, as well as pure 32-bit code. However, when
32-bit interrupt handlers are present, 16-bit code should avoid any
dependence on the upper word of ESP. No changes are necessary in existing
16-bit code, since the only way to access ESP in USE16 segments is
through the 32-bit address size prefix."</P
><P
>Unfortunately, the above quote from Intel is silent about the 32-bit
programs that use 16-bit stack segment - this is where the problem pops us.
The corruption happens when the Linux kernel returns control to the dosemu
process, while a 32-bit DPMI client that uses a 16-bit data segment for
the stack is active. This is not the usual case, but unfortunately some
32-bit DPMI clients are actually using a 16-bit segment for the stack,
and even the dos4gw extender behaves that way sometimes.</P
><P
>Programs that are known to be affected by this issue are:
<P
></P
><UL
><LI
><P
>Need For Speed 1 (demo version at least, when configured with sound)</P
></LI
><LI
><P
>Syndicate Wars (when used with dos4gw 0.8)</P
></LI
><LI
><P
>Open Cubic Player</P
></LI
></UL
></P
><P
>These programs are crashing shortly after startup, but this problem
is difficult to detect reliably, so there may be many more programs
that experience a random crashes due to this CPU bug.</P
><P
>The reliable work-around was developed and added into linux-2.6.12
for 32-bit systems, and into linux-3.16 for 64-bit systems.</P
><P
>Note: linux kernels prior to 3.16 may have various problems on x86-64.</P
></DIV
></DIV
></DIV
><DIV
CLASS="SECT1"
><HR><H2
CLASS="SECT1"
><A
NAME="AEN69"
>2. Known bugs</A
></H2
><DIV
CLASS="SECT2"
><H3
CLASS="SECT2"
><A
NAME="AEN71"
>2.1. Things YOU may help changing</A
></H3
><DIV
CLASS="SECT3"
><H4
CLASS="SECT3"
><A
NAME="AEN73"
>2.1.1. List of currently known bugs in dosemu2</A
></H4
><P
></P
><UL
><LI
><P
>Some documentation is known to be well out of date. </P
></LI
><LI
><P
>Some database programs (Clipper, FoxPro) have problems with
locking in certain configurations. smbfs doesn't support
locking. $_full_file_locks=(on) may or may not help.</P
></LI
><LI
><P
>Mortal Kombat 1 and 2 are not producing any sound for unknown reasons.</P
></LI
><LI
><P
>X-COM Apocalypse (DEMO version) locks up at startup if configured with sound.</P
></LI
></UL
></DIV
></DIV
></DIV
><DIV
CLASS="SECT1"
><HR><H2
CLASS="SECT1"
><A
NAME="AEN84"
>3. Programs exhibiting graphical problems in xdosemu</A
></H2
><P
>The following programs work perfectly on the Linux console
(suid/sudo/root) with graphics enabled but exhibit minor or
major glitches in xdosemu.</P
><DIV
CLASS="SECT2"
><HR><H3
CLASS="SECT2"
><A
NAME="AEN87"
>3.1. Games with graphical problems</A
></H3
><P
>The following games exhibit glitches or don't work at all in
xdosemu. Please let us know when any problems are solved or
even better, help us solving!</P
><P
></P
><UL
><LI
><P
>Commander Keen 1 wobbles like jelly and the window shakes
every time it scrolls.</P
></LI
><LI
><P
>Pinball Dreams 2 takes a long time to start. Once it's past
the startup screen it runs fine though.</P
></LI
></UL
></DIV
></DIV
><DIV
CLASS="SECT1"
><HR><H2
CLASS="SECT1"
><A
NAME="AEN95"
>4. Differences in behaviour between Dosemu and Dosemu2</A
></H2
><P
>The following differences may be apparent if you have previously been
using Dosemu.</P
><DIV
CLASS="SECT2"
><HR><H3
CLASS="SECT2"
><A
NAME="AEN98"
>4.1. Filesystems</A
></H3
><DIV
CLASS="SECT3"
><H4
CLASS="SECT3"
><A
NAME="AEN100"
>4.1.1. MFS</A
></H4
><P
>Network device DOS filesystem that provides read write access to the host filesystem.</P
><P
></P
><UL
><LI
><P
>Dosemu2 does not redirect a drive to arbitrary host paths on the command
line of the emufs.sys driver when it is loaded in config.sys. Use the lredir2
command to accomplish this in autoexec.bat instead.</P
></LI
><LI
><P
>Dosemu2 does not support LFN on the SUBST / JOIN drives.</P
></LI
><LI
><P
>Dosemu2 now provides enhanced FAT32 disk functions only as a fallback
to the native DOS in the event that the DOS does not implement them itself.
A consequence of being a fallback is that if the DOS has a bug in its
implementation it is not overriden by Dosemu2. Examples of this are
MS-DOS 7.0 and PC-DOS 7.10.</P
></LI
></UL
></DIV
></DIV
></DIV
></DIV
></BODY
></HTML
>

430
doc/NOVELL-HOWTO.txt Normal file
View File

@@ -0,0 +1,430 @@
Netware-HOWTO
Lauri Tischler ltischler@fipower.pp.fi
rev.0.2 30 Mar 1995
updated for DOSEMU 1.2.0, 18 Jan 2004, Bart Oldeman -- contributions
by Peter Eckhardt
This document tryes to descibe how to connect to Novell Netware
servers from Linux.
1. Introduction
Due to the limited scope of this note, it is not a real HOWTO, not
even a 'mini-HOWTO'. You might call it a 'nano-HOWTO' if you like.
In most sites the Netware is really just an extension to PC's running
DOS and DOS applications (Windows is JUST another DOS-application),
the Netware providing fileserver and printing support.
I will concentrate on getting the connection via DOSEMU only.
My everyday network is a Netware network with 3 servers and appr. 110
PC's connected to it. It is TOTALLY Dos/Windows environment, running
Novell standard Ethernet_802.3 frames, very ordinary REAL LIFE setup.
Tested Environment :
o LinuxBox 486DX2/66, 17Meg Ram + 20 Meg Swap, two ESDI disks 340Mb
and 320 Mb (Linux InSide), Netcard SMC Elite Ultra.
o Linux 1.2.2, Dosemu pre0.53.55.
o Netware 3.11 on all servers, SMC Elite 32 EISA on main server.
The following may or may not work on Your pile of iron.
2. Netware Requirements.
One of the main questions is What Is the Ethernet Frame Type your
Netware uses.
2.1. Frametype Ethernet_II.
For IP-connectivity Novell has always used Ethernet_II frametype.
Some sites use Ethernet_II for IPX _and_ IP (good for them). This is
also easiest case to connect to Netware, you also get IP-connectivity
between your linuxboxes if/when they are located in separate segments.
For IP-connectivity you need to load TCPIP.NLM in your server and
define FORWARD=YES on loadline. You also need to BIND the IP to your
server networkcards with proper IP-address. In general if you need
any kind of IP-connection to Netware Server (NFS, BOOTPD, FTPD) you
_must_ use Ethernet_II frame.
2.2. Frametype Ethernet_802.3.
Traditionally Novell has used Ethernet_802.3 for IPX protocol. That is
_before_ the Netvare 4.0x and various VLM stuff. In this case you
can't communicate with other linuxboxes if they are located on
separate segments because Netware will not route IP-protocol on 802.3
frames. You can however connect to Netware server as an isolated
workstation.
2.3. Frametype Ethernet_802.2.
New Novell practice is to recommend the Ethernet_802.2 frame for IPX.
The 802.2 is actually the default frametype unless otherwise declared
(in server autoexec.ncf and workstation net.cfg files). This is also
the worst case because the dosemu packetdrivers do not support this
frametype. You can still connect using direct-IPX approach.
I would recommend that you load the Ethernet_II frame in your server
in ANY CASE because that makes the care-and-feeding-and-development
much easier in the longrun.
There has been some worried noises about messing up the IP-traffic on
Ethernet_II if you run IPX on Ethernet_II frames at the same time.
There is no problem in running both protocols on same frame and cable,
it is done all the time on many sites (RTFM - Novell TCP/IP Docs) 8-).
This how I do both frames and protocols on single card and cable .
load SMCE32 port=6810 Name=First Frame=Ethernet_802.3 ; 'novell' frame
load SMCE32 port=6810 Name=Second Frame=Ethernet_II ; 'normal' frame
bind ipx to First Net=E1
bind ipx to Second Net=E2
So I actually run IPX on both frames, Ethernet_802.3 on logical net E1
and Ethernet_II logical net E2. All on one card and cable.
3. Making The Connection.
There are basically two methods for making the connection between the
Linuxbox and Netware server, The Direct-IPX or Packet Drivers. At
the time of writing the Packet Driver method is the most reliable
in particular if you combine it with DPMI programs. Direct-IPX may
just work though (depending on the DOS program in question).
3.1. The Direct-IPX.
Make sure that you have the IPX support compiled in to your kernel.
Within DosEmu, in directory ipxutils, there are some utilities which
are necessary. At the time of this writing the compiling of those
utilities was not automatic, so it may be necessary to go to
directory ipxutils and run 'make'.
Check that in your 'dosemu.conf' file you have 'ipx_support' enabled.
$_ipxsupport = (on)
Now you need to enable the ipxinterface. To do that you execute
following command :
ipx_interface add -p eth0 802.3
Instead of 'eth0' you can give some other Id in case your ethernetcard
is somewhere else.
The last parameter, ie. 802.3, depends on what type of ethernetframe
runs on your network. Possibe values are 802.2, 802.3 and EtherII.
Check with your Netware Administrator if you are not sure. You may
wish to add the above mentioned command into your rc.local file.
Now start the dosemu session and load the Netware shell, NETX. The
NETX is the only TSR necessary to run the connection, no LSL, no
Packetdrivers nor IPXODI.
Pros.
o Connection is reasonably fast, about 2.41666.. times faster then
packetdrivers.
o This is the ONLY way to connect if you are using Ethernet_802.2
frame.
Cons.
o SPX support is still missing, this means that some software will
not run, like Intel LanDesk Inventory, Novell Remote Console,
Netware Access Services, I'm sure there are more 8=(
o The connection drops dead after about 15 min of idletime. I
suspect that it has something to do with 'watchdog packets' from
the server not getting proper answer. Maybe some IPX/SPX guru will
look into this.
o DPMI in combination with direct IPX is broken as of DOSEMU 1.2.0.
3.2. The Packet Driver (IPX).
As a driver you should use PDETHER which is an ipx-to-packet driver
shim, but masquerading as an ODI compliant driver. There also exists
an older driver PDIPX, technology represented by PDIPX is no longer
supported by Novell. A driver named IPXPD is more likely to work
than PDIPX. PDETHER and IPXPD are using Ethernet_II frames, while
PDIPX uses 802.3 frames.
The Packet Driver uses build-in packetdriver interface which means
that the IPX-SUPPORT in Kernel and in DOSEMU is NOT needed. When
configuring the Kernel you can define IPX-SUPPORT (n), this is
actually the default case.
Corresponding parameter for DOSEMU is found in the NETWORKING SUPPORT
section of dosemu.conf/.dosemurc. There you just leave the line
$_ipxsupport = (off) commented out. (see below)
The use of the second configuration parameter $_novell_hack is
explained in detail in later paragraphs.
#************************* NETWORKING SUPPORT *****************************
#
# Turn the following option 'on' if you require IPX/SPX emulation.
# Therefore, there is no need to load IPX.COM within the DOS session.
# The following option does not emulate LSL.COM, IPXODI.COM, etc.
# NOTE: MUST HAVE IPX PROTOCOL ENABLED IN KERNEL !!
# $_ipxsupport = (off)
#
# Enable Novell 8137->raw 802.3 translation hack in new packet
# driver.
$_pktdriver = (on)
# $_novell_hack = (off)
Also set up a working packet driver (eg. TUN/TAP) connection; refer to
README.txt for details. For example (with tunctl) set:
$_netdev="tap0"
$_vnet="tap"
There are various versions of the packetdriver PDETHER floating around, but
it is recommended to use version 1.05 or later. Those versions have
support for a "raw packet send" interface.
PDETHER in its native mode understands only Ethernet_II frames, by
enabling the dosemu.conf parameter pktdriver novell_hack it can be
fooled to use Ethernet_802.3 frames instead.
Because PDETHER is an ODI driver, you load..
LSL (at least version 2.20; older versions may crash dosemu)
PDETHER
IPXODI
NETX
If you use IPXPD or PDIPX you just load
IPXPD (for Ethernet_II frames) or PDIPX (for 802.3 frames)
NETX
Because PDETHER is an ODI driver, there must be corresponding section
in your net.cfg file. Here is a snippet of my NET.CFG
Link Support
Buffers 4 1514
MemPool 2048
Link Driver PDETHER
Int 60
FRAME Ethernet_II
NetWare DOS Requester
FIRST NETWORK DRIVE = F
SHOW DOTS = ON
SET STATION TIME = ON
PREFERRED SERVER = HOME
FILE HANDLES = 40
LOCAL PRINTERS = 1
The packetdrivers support only Ethernet_802.3 and Ethernet_II frames.
If you are unlucky enough to use Ethernet_802.2 frame, your only
change is to use direct-IPX interface (unless you can persuade the
system admin to add Ethernet_II frames to your network 8=)).
Do NOT CHANGE line 'FRAME Ethernet_II' in Link Driver PDETHER section,
instead enable or disable the 'pkdriver novell_hack' in 'dosemu.conf'
$_pktdriver = (on)
$_novell_hack = (on) If you have Ethernet_802.3
# $_novell_hack = (off) If you have Ethernet_II
Read the PDETHER.DOC for further info.
Example from Peter Eckhardt:
Create a startnet.bat and net.cfg in dosemu
CD C:\NWCLIENT
edit ....
- startnet.bat -
SET NWLANGUAGE=DEUTSCH
LH C:\NWCLIENT\LSL /c=C:\NWCLIENT\net.cfg
C:\NWCLIENT\PDETHER.EXE
LH C:\NWCLIENT\IPXODI.COM
rem LH C:\NWCLIENT\NETX
LH C:\NWCLIENT\VLM.EXE
- net.cfg -
Link Support
Buffers 4 1514
MemPool 2048
Link Driver PDETHER
Int 60
FRAME Ethernet_II
USE DEFAULTS=OFF
VLM=CONN.VLM
VLM=IPXNCP.VLM
VLM=TRAN.VLM
VLM=SECURITY.VLM
VLM=NDS.VLM
VLM=NWP.VLM
VLM=FIO.VLM
VLM=BIND.VLM
VLM=PRINT.VLM
VLM=GENERAL.VLM
VLM=REDIR.VLM
VLM=NETX.VLM
NetWare DOS Requester
FIRST NETWORK DRIVE = F
NETWORK PROTOCOL = BIND
SHOW DOTS = ON
SET STATION TIME = ON
PREFERRED SERVER = EMK1
FILE HANDLES = 40
LOCAL PRINTERS = 1
VLM = AUTO.VLM
4. Speed Of Connection
Here is some benchmarking I did with testprogram TESTNET.EXE,
available somewhere in NetWire. It tests the network transfer speed.
I can saturate my ethernet with two stations running at full tilt.
Maximum aggregate speed is appr. 900 kilobytes/sec.
I'm using SMC Elite 32 EISA board in Server and SMC Elite Ultra in
workstation.
NETX
Dos6.2 620
DosEmu (directIPX) 290
DosEmu (pktdrv) 120
The figures denote transferspeed in kilobytes/second.
Few months ago I had a NE2000 clone in my box, with DOS6.2/NETX it
would run to appr. 460 kbs. I could live with that.
Note: Recently improvements were made that speed up the packet
driver throughput more than twice. The above measurements are no longer
valid. It is expected that the Packet Driver now has the same performance
as the directIPX method, or even better, but no precise measurements
were made.
5. NFS and Other Connectivity.
It is possible to access Netware server and services from Linux
directly by using various commercial supportpackages to get Unix
filesystem and/or printing services.
o Netware-NFS.
o Netware Flex-IP.
o Nov*iX from FireFox.
o Charon, shareware SMTP-gateway and printservices.
There also exists a freeware NFS connectivity using SOSS package,
below is a contribution from a fellow netter, Andrew J. Anderson,
andrew@db.erau.edu.
--- message begins ---
I am currently using a package called "soss" (Son of Stan's Server)
that turns a DOS PC into an NFS server. I am using this to export
NetWare volumes to my Linux box so that I can have multi-user access
to several CD-ROM packages. I will continue using this until multiple
logins from DOSEmu becomes a reality. The speed of this setup depends
on the speed of the PC that is running the NFS server package.
Currently, I am using a 286 with 4 Megs of RAM being used as a disk
cache. If I remember correctly, I can get about 50K/s across this
setup. I tested a 486DX-33 with 8 megs and got about 250- 300K/s
transfer. I am hoping to get about 500K/s with a 486DX2-66 with 16
megs of RAM. Not blazingly fast, but good enough.
So if you play with drive mappings under DOSEmu using LREDIR, you
could setup a scheme where each user had a mapping to their home
directory on the Novell side. There is potential for security risk in
doing that because SOSS doesn't have much in the way of security built
in, but I am using part of my NetWare volumes as "overflow" space when
my Linux drives fill up -- as they so often do! :)
--- message ends --- Thanks Andrew..
I have no personal experience with any of the packages mentioned
above, I'm sure that there are a lot of other useful packages
floating around. Please mail me, so I can add them to possible future
incarnations of this note.
6. History.
6.1. Revision 0.1.
Written with great haste and enthusiasm. Contained some mistakes for
which I was promptly flamed 8:). Some reports of success were also
received.
6.2. Revision 0.2.
Known errors corrected and new sections added.
Any additions for this HOWTO are humbly accepted and if relevant to
great cause will be added to later revisions.
7. Begin Legalese.
Unless otherwise stated, Linux HOWTO documents are copyrighted by
their respective authors. Linux HOWTO documents may be reproduced and
distributed in whole or in part, in any medium physical or electronic,
as long as this copyright notice is retained on all copies. Commercial
redistribution is allowed and encouraged; however, the author would
like to be notified of any such distributions.
All translations, derivative works, or aggregate works incorporating
any Linux HOWTO documents must be covered under this copyright notice.
That is, you may not produce a derivative work from a HOWTO and impose
additional restrictions on its distribution. Exceptions to these rules
may be granted under certain conditions; please contact the Linux
HOWTO coordinator at the address given below.
In short, we wish to promote dissemination of this information through
as many channels as possible. However, we do wish to retain copyright
on the HOWTO documents, and would like to be notified of any plans to
redistribute the HOWTOs.
If you have questions, please contact Greg Hankings, the Linux HOWTO
coordinator, at greg.hankings@cc.gatech.edu. You may finger this
address for phone number and additional contact information.
End Legalese.
Happy Netting. Lauri Tischler, ltischler@fipower.pp.fi

63
doc/README.gdb Normal file
View File

@@ -0,0 +1,63 @@
From lermen@elserv.ffm.fgan.de Fri Jan 9 02:02:28 1998
Date: Sun, 4 Jan 1998 16:30:24 +0100 (MET)
From: Hans Lermen <lermen@elserv.ffm.fgan.de>
To: Marty Leisner <leisner@sdsp.mc.xerox.com>
Cc: Pat Villani <patv@iop.com>, dosemu developers <dosemu-devel@suse.com>
Subject: Re: Ideas for debugging
On Sat, 3 Jan 1998, Marty Leisner wrote:
>
> In order to run gdb under dosemu:
> attach (compile with the -g option)
> do
> handle SIGSEGV nostop noprint
>
> then you're fine
Yup, that's the trick ;-)
However, to 'compile with -g' one has to do:
make pristine
./default-configure --enable-debug
make
> (but its very difficult to debug programs under
> dosemu).
its nearly impossible, for that we have 'dosdebug', the bultin debugger.
>
> Several years we discussed this...has any work been done essentially
> having dosemu act as a gdbserver, which can talk to gdb...??
hmm, can gdb handle 16 bit code or even segmented code?
Hans
<lermen@fgan.de>
Bart:
It can handle 16 bit code but you have to handle the segmentation yourself,
e.g. use
set architecture i8086
x/20i 0x9089*16+0x18e
to dump 9089:019e
Another issue is that whilst single stepping the SIGALRM handler may
disturb. You can avoid that using hooks, as below, and paste everything
into a .gdbinit file.
define hook-stop
handle SIGALRM nopass
end
define hook-run
handle SIGALRM pass
end
define hook-continue
handle SIGALRM pass
end
handle SIGSEGV nostop noprint

6096
doc/README.html Normal file

File diff suppressed because it is too large Load Diff

1023
doc/tweaks.html Normal file

File diff suppressed because it is too large Load Diff