1.2.0 binary install

1.2.0 binary install

[Jan Willem Stumpel]

The install from source works beautifully. I love dosemu; I think
the developers are great people, very helpful and responsive. This
surely must be one of the best projects in the free software world.

But I would like to have dosemu available to dummies, a.k.a.
ordinary users.

I tried out the binary install. First, very thoroughly, I removed
all previous installations of dosemu, freedos, and the dosemu fonts.

Then I downloaded from www.dosemu.org

dosemu-1.2.0-bin.tgz
dosemu-freedos-b9-bin.tgz

A) I did what README.bindist says.

$mkdir mydos
$cd mydos
$tar -zxf dosemu-freedos-bin.tgz
tar (child): dosemu-freedos-bin.tgz: Cannot open: No such file or
directory
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error exit delayed from previous errors

Oops. The tarball should have been moved into ~/mydos first. This
is obvious, but not obvious to dummies.

B)
$cd
$cd mydos
$mv ../dose*z .

Again we follow the instructions in README.bindist:

$tar -zxf dosemu-freedos-bin.tgz
tar (child): dosemu-freedos-bin.tgz: Cannot open: No such file or
directory
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error exit delayed from previous errors

Ahh.. the name of the file is different. Why, BTW? We should
rename it, according to the dosemu.org homepage, when we compile
from source. But we are using the binary distribution!

C) Third attempt

$tar -zxf dosemu-freedos-b9-bin.tgz
$tar -zxf dosemu-1.2.0-bin.tgz

This works. BTW why -zxf instead of vzxf? The v option gives some
reassuring feedback to users.

$ cd mydos

$ ./xdosemu
ERROR: X: Unable to open font "vga"ERROR: , trying "vga"...
ERROR: X: Unable to open font "vga"ERROR: , trying "9x15"...

And an x-dosemu window opens using an X terminal font. The binary
install can´t do the xset trick for including Xfonts in the font
path.

The same, of course, happens if you do NOT create a subdir called
mydos. The dosemu-bin and dosemu-freedos packages can also just be
unpacked from ~ (where the Ordinary User normally downloads it),
with all the stuff ending up in ~/dosemu. So why mydos?

Of course these problems are trivial for reasonably sophisticated
users. But many ordinary users just give up. Can´t we *at the very
least* provide some instructions which, if followed to the letter,
make the software work? Isn´t this worth some effort?

Regards, Jan

-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 1.2.0 binary install

[Ged Haywood]

Hi Jan,

On Thu, 22 Jan 2004, Jan Willem Stumpel wrote:

> install from source works ... love dosemu ... developers are helpful
> & responsive ... one of the best projects in the free software world.

I agree, the project is in good shape.

> like to have dosemu available to dummies, a.k.a. ordinary users.

Good point.

> I tried out the binary install.

I've never done that.

> This works. BTW why -zxf instead of vzxf? The v option gives some
> reassuring feedback to users.

Actually I dislike the verbosity, but 'v' option or not, the tar
manpage on my boxes says:

"The first argument to tar must be one of the options: Acdrtux,
followed by any optional functions."

So I think you should say "tar xvzf" not "tar vzxf".  I'm sure that
there are versions of tar that will cope with either, although I'm not
sure that all of them will understand the 'z' option.  The leading '-'
may or may not be optional.  On balance, for newbies it might be better
to split up the extraction into separate decompress and untar steps.

> The same, of course, happens if you do NOT create a subdir called
> mydos. The dosemu-bin and dosemu-freedos packages can also just be
> unpacked from ~ (where the Ordinary User normally downloads it),
> with all the stuff ending up in ~/dosemu. So why mydos?

I made similar points back in March last year about the source install.
Looks like the binary install was overlooked.

> Can't we *at the very least* provide some instructions which, if
> followed to the letter, make the software work? Isn't this worth
> some effort?

I'm sure it is.  Sounds like time to send in a documentation patch.
I tell you what.  You write it, I'll test it.  Deal?

73,
Ged.

PS: Do you always send UTF-8?  I had to edit the apostrophes in that
last sentence of yours... :)

Re: 1.2.0 binary install

[norseman]

Jan Willem Stumpel wrote:
> 
> Ged Haywood wrote:
> 
> > Actually I dislike the verbosity,
> My point was that I think *dummies* like the verbosity. If you are
> a dummy, then of course I am mistaken.
> 
> > but 'v' option or not, the tar manpage on my boxes says: [..]
> Linux as a whole (not only dosemu) suffers from incredibly bad
> documentation. xfzv works, and has worked for years, in any
> permutation.
> 
> > Sounds like time to send in a documentation patch. I tell you
> > what.  You write it, I'll test it.  Deal?
> You never (as you said) even tried the binary install. Some
> tester! But I did. Let's do it the other way round: you make it
> work (including the font part), then I write the doc. Deal?
> 
> Seriously: I think the binary install should do exactly the same
> that the (excellent) source install does; i.e. it should put
> exactly the same files in exactly the same locations (/usr/local)
> that are used by ./configure, make, [become root] make install. It
> should just free the dummy user from the compilation step, for
> which he/she most probably lacks the tools, and would be
> confronted with (to her/him) incomprehensible error messages
> because of that. It should (like the source install) also be
> independent of freedos, because dosemu itself is independent of
> it. Like the source install, it should ask which directory is the
> 'C drive'. If user/dummy does not know, it should be pointed out
> that some form of DOS is needed, and installation of freedos offered.
> 
> > PS: Do you always send UTF-8?
> In principle, yes.. but in Mozilla, apostrophes often behave
> weirdly, don't quite understand why. ASCII is supposed to be valid
> UTF-8. 'Send'? '73'? Radio?
> 
> Regards, Jan
> 
======================================

Go get'm Jan!

I agree 100% with you.


As long as things are getting cleaned up:
	I suppose it makes one think their project is bigger if they
scatter it out all over the damn place. But I suggest something like:
		$HOME/.dosemu 	       drives/and user's config and such
		/usr/local/dosemu      EVERYTHING else
If having a hundered directories makes one feel more important, or just
not able work without them, have at it in this one spot.

BIG NOTE:
	MSDOS itself does not support record or file locking. 
Linux does and DOSEMU.bin can enforce. ONE user at a time please.
Applies to /usr/local/dosemu/freedos and actual MSDOS partitions.
exception:  if a $HOME/freedos is used.  Then each user would have
his/her own dos world and locks would not apply.

Steve Turner
norseman@firstlight.net

Re: 1.2.0 binary install

[norseman]

Bart Oldeman wrote:
> 
> On Fri, 23 Jan 2004, Jan Willem Stumpel wrote:
> 
> > Seriously: I think the binary install should do exactly the same
> > that the (excellent) source install does; i.e. it should put
> > exactly the same files in exactly the same locations (/usr/local)
> > that are used by ./configure, make, [become root] make install. It
> > should just free the dummy user from the compilation step, for
> > which he/she most probably lacks the tools, and would be
> > confronted with (to her/him) incomprehensible error messages
> > because of that.
> 
> In that case the RPM install is more appropriate. Seriously when I created
> the RPM I was wondering if I should still provide the tarball; in general
> users vote with feet so I put it up for rc1 and watched the statistics.
> 
> For 1.1.99.1 we have from SF
> http://sourceforge.net/project/showfiles.php?group_id=49784
> RPM            : 9490 downloads
> Source RPM     : 2906
> binary tarball : 3976
> source tarball : 7148
> source patch   :  435
> 
> So it looks like the RPM is the most popular, but there is still
> significant demand for the binary tarball.
> 

I suspect all the RPM people got together and padded the count.
The more I see and use of RPM the less I like it.
It is a potential security risk.  Please don't go there.


> The point about the binary tarball (as Hans Lermen explained it, as far
> as I know) is that you can quickly and easily check out DOSEMU in your
> home directory *without needing root*. He thought building RPMs, deb's and
> so on was a job for distributors (many of them who get paid for just doing
> that after all, and we don't...)
>

Go Hans Go
 
> But.. DOSEMU isn't as important anymore as it used to be and some
> distributions no longer have it.
> 

Do not think of "not included" as "not important".
If you don't understand - ask Cinderella.
	(the one with the ugly step-sisters who kept excluding her)

> For instance, for Red Hat versions:
> 6.0 (Apr 99) and all previos Red Hats had it in base (DOSEMU 0.99.10)
> 6.1 (Sep 99) also (ver 0.99.13)
> 6.2 (Feb 2000) moved it to the extras in "powertools" (0.99.13)
> 7.0 (Aug 2000) powertools (1.0.1)
> 7.1 (Mar 2001) powertools (1.0.1)
> 7.2 (Sep 2001) dropped it and Bernhard Rosenkraenzer maintained the
> previous RH rpm privately.
> 
> DOSEMU 1.0.2 (the one where the binary tarball was introduced) was
> released in June 2001.
> 
> > It should (like the source install) also be
> > independent of freedos, because dosemu itself is independent of
> > it.
> 
> I don't agree with that completely; that's why I included FreeDOS in the
> rpm. The point of the RPM is to be able to:
> 
> rpm -i dosemu-1.2.0-1.i386.rpm
> xdosemu
> and it just works after answering a few questions. As part of those
> questions the user may point to another DOS if he wants to but he should
> be able to just press [Enter] a couple of times and it just works.
> 
> If another DOS is used; yes it's a bit of a waste of bandwidth but that's
> the price you pay. And anyways many programs (think about mozilla!) are
> much much larger than the 2MB DOSEMU rpm.
> 

...mozilla  there is a big difference between big and bloated.

> Debian users could use alien (or just get the Debian package from Debian;
> 1.2.0 is in sid now).

tar comes with all Unix and gzip is easy to get. Why waste the
time/effort?
mc lets one see the "inside" of tar and tgz files and even alows one
to get the single replacement for the file one just dammaged without
doing
the MicroSoft complete start over thing.

> 
> So -- perhaps your DOSEMU for dummies page should point to the RPM
> instead?
> 

again PLEASE - NO

> Anyway, i would welcome any documentation updates! There are even a few
> things on the web you could look at, e.g.
> http://www.wordstar2.com/dos6steps.htm
> http://www.linux2000.com/stsplus-linux.html
> http://www.rkka.org/Campaigns/dehowto.htm
> http://www.rkka.org/Campaigns/lindosfaq.htm
> http://ostrab2.potsdam.edu/CIS310/mydos/install.html
> http://www.linuxandmain.com/modules.php?name=News&file=article&sid=363
> "is the bee's knees as far as installation goes" -- can't be _that_
> difficult then ;)
> 
> About the font problem. I honestly don't know what is going on. Between
> rc1 and rc2 I added some attempts to desperate get xset +fp ... working
> but apparently there's still something broken, but only for some people;
> for me it can find the font just fine. Seems to depend on the X server
> configuration. But I honestly don't know... I just can't reproduce.
> 

has anyone tried compile, install, startx, term, xset +fp, xset rehash
(or whatever you system wants for new x fonts) BEFORE starting DOSEMU?

It has been so long since I went thru that. Seems I had to install
DOSEMU
several times before I got the sequence right. I think that is what it
was.
2001 to 2004 ... well it seems longer. :)

speaking of adding things:
	1) pre-compiles need to actually read a config file and accept
		.emu extensions instead of ignoring them.
	2) need to put himem and UMB back into operation. 1.1.99.1 reduced
		available memory considerably. (canceled compress.exe use)

> Bart
> 
================

Steve Turner
norseman@firstlight.net

Re: 1.2.0 binary install

[norseman]

Justin Zygmont wrote:
> 
> > BIG NOTE:
> >       MSDOS itself does not support record or file locking.
> > Linux does and DOSEMU.bin can enforce. ONE user at a time please.
> > Applies to /usr/local/dosemu/freedos and actual MSDOS partitions.
> > exception:  if a $HOME/freedos is used.  Then each user would have
> > his/her own dos world and locks would not apply.
> 
> what if they are sharing the same msdos partition or boot directory?
============================

You and I can't use the same actual dos machine at the same time -
right?

Same goes for non-user-directory installs.

Per the Highlander:  "There can be only One"   at a time.

IF and ONLY IF (IFF) the simultanious use of DOSEMU is on DIFFERENT
partitions or home directories is file locking not a factor.
Screw up your tax records and IRS will eat you alive. So will their
counterparts in other countries.

Steve Turner
norseman@firstlight.net

Re: 1.2.0 binary install

[norseman]

Justin Zygmont wrote:
> 
> > Seriously: I think the binary install should do exactly the same
> > that the (excellent) source install does; i.e. it should put
> > exactly the same files in exactly the same locations (/usr/local)
> > that are used by ./configure, make, [become root] make install. It
> > should just free the dummy user from the compilation step, for
> > which he/she most probably lacks the tools, and would be
> > confronted with (to her/him) incomprehensible error messages
> > because of that. It should (like the source install) also be
> > independent of freedos, because dosemu itself is independent of
> > it. Like the source install, it should ask which directory is the
> > 'C drive'. If user/dummy does not know, it should be pointed out
> > that some form of DOS is needed, and installation of freedos offered.
> 
> well, a compresed tar file will extract itself relative to your current
> path, so you can't really have it install to /usr/local by default, it's
> not usually a problem anyways.  There is the RPM that might be preferrable
> for you, dosemu is much easier than it used to be.
> 
sound the gong!

tar -xzfP tarfile will install absolute if 
tar -czfP tarball / was used


OK-OK simmer down class.
   cd someplace with space  (/tmp)
   mkdir a dummy directory  (/tmp/d)
   cd the dummy dir         (pwd -> /tmp/d )
   mkdir usr
   mkdir usr/local
   mc /usr/local ./usr/local
   arrow down to dosemu
    <F5>  and copy branch
   <F10>
   tar -czPf /anotherplace/tarfile /

get the picture?
done?
clean up your disk!

the -P retains leading "/"

Steve Turner
norseman@firstlight.net

Re: 1.2.0 binary install

[norseman]

Bart Oldeman wrote:
> 
> On Fri, 23 Jan 2004, norseman wrote:
> 
> > As long as things are getting cleaned up:
> >       I suppose it makes one think their project is bigger if they
> > scatter it out all over the damn place. But I suggest something like:
> >               $HOME/.dosemu          drives/and user's config and such
> >               /usr/local/dosemu      EVERYTHING else
> > If having a hundered directories makes one feel more important, or just
> > not able work without them, have at it in this one spot.
> 
> The FHS would actually favour /opt/dosemu instead of /usr/local/dosemu in
> this case. But this is problematic for several reasons:
> * you'd have to add something like /usr/local/dosemu/bin to your PATH
>   (otherwise a simple "dosemu" wouldn't work)
> * you'd have to add something like /usr/local/dosemu/man to your MANPATH
>   (otherwise "man dosemu" wouldn't work)
> so this is why "make install" puts most things in /usr/local/share/dosemu,
> and only the binaries, manpages, and documentation in other places.
> 

OK Class - pay attention:
	cd /usr/local/bin
        ln -s /usr/local/dosemu/bin/file1  file1
        ... repeat as needed
        cd /usr/local/man 
        do I really need to type all this out?
The bonus is: if real file is missing - it shows up in the soft link
listing.

again:  /usr/local/share/dosemu  is just more typing.
        /usr/local/dosemu        see?

> > BIG NOTE:
> >       MSDOS itself does not support record or file locking.
> 
> this is wrong: it sure does! MSDOS has had to deal with network drives for
> many years, since version 3.0. That's one of the reasons why the DOS
> "SHARE" command exists.
>
CLASS!!! SHARE is there for MSDOS programs that use SHARE
	name 10
	better yet - name 1 non-network/non-oversystem related DOS program 
        that uses SHARE
 
> > Linux does and DOSEMU.bin can enforce.
> 
> dosemu.bin tries to emulate file locking; if DOS tries to lock a file,
> then Linux tries to lock it. The main trouble is that these interfaces are
> horribly incompatible; it'll probably work but there are exceptions.

I'm not expecting DOSEMU or Linux to care what DOS does.
The DOSEMU will lock other DOSEMU users from the DOS system already in
use.
If one manages to run TCP or other net program from DOS - IT (they) will
take
care of DOS problems, if it (they) can.  If we are going to be DOS,
let's be DOS.


> 
> > Applies to /usr/local/dosemu/freedos and actual MSDOS partitions.
> > exception:  if a $HOME/freedos is used.  Then each user would have
> > his/her own dos world and locks would not apply.
> 
> /usr/local/share/dosemu/freedos is usually readonly (except for root).
              ^ this is getting boreing.


> Actual MSDOSpartitions or anything else that is writable are like network
> drives. DOS applications that must care about locking already have done
> so for many years. So I'm not sure what you're up to here.

I used a real MSDOS 6.22 bootable disk under DOSEMU 1.0.2 and I have
absolutely no idea of what you are talking about. DOS apps do not do
locks!
MSDOS does not do network. Does not do multiuser. Does not do multitask.
It is one user on one keyboard doing one program at a time. Period.
There are/have_been programs that attempted to push MSDOS into "more
productive" realms. Those of us from the assembly world can only
cough politely at the thought of a totally interrupt driven OS even
thinking about being multitasking. :)  Yes - I'm aware of a few
proprietary
overlays for controlled use. And the problems associated.
YES - 1.0.2 and 1.1.99.1 do require a disk partition to be dismounted
before they run. But I can and did open several DOSEMU "windows" 
simultainously. Hell of a good way to screw up files if one isn't very
careful.
Xtreegold, dBASE III+ WordStar 4 and a ton of other software I run on 
MSDOS have absolutely no concept of file locking. And never did.

Past tense used because recompiles of 1.0.2 and 1.1.99.1 fail to
function
on new hardware. Same OS, same install - new laptop. Fail Totally.  
Entire program might as well be a single exit() function. No
errors, no nothing. Just a simple return to system prompt.

I have downloaded 1.2 and will give it a try - hopefully this weekend.

> 
> Bart


================

Traditionally:
	In UNIX
		/bin /sbin and such are OS system files
		/usr/bin /usr/sbin and such are login's files
		/usr/local/bin /usr/local/sbin and such
			are files specific to local hardware and console use.
			like cdrecord (you know how - get the image onto
			a local drive, drop the net, make the burn and
			restart the net. Or have lots of coasters.)

Pardon my sharpness: I've been using DOSEMU since 0.66 and not having
it avaliable is serriously cramping my style at work. Makes me cranky.

Also notes its value to the working world. Keep going guys.

Steve Turner
norseman@firstlight.net

Re: 1.2.0 binary install

[norseman]

Bart Oldeman wrote:
> 
> On Fri, 23 Jan 2004, norseman wrote:
> 
> > I suspect all the RPM people got together and padded the count.
> 
> wow. Conspiracy theory. We love that right ;)

just had to toss that in. :)

> 
> > The more I see and use of RPM the less I like it.
> > It is a potential security risk.  Please don't go there.
> 
> RPM was selected by the people at www.linuxbase.org (LSB) as the standard
> binary distribution format. These are knowledgeable people. If RPM were a
> real security risk it wouldn't have been selected.
> 

And we all trusted Bill too.  :) more fun


> > speaking of adding things:
> >       1) pre-compiles need to actually read a config file and accept
> >               .emu extensions instead of ignoring them.
> 
> what do you mean here? $_emusys in dosemu.conf?

no;   .emu extensions to autoexec and config so one doesn't have
to continually copy dummies to .bat .sys if booting live and
another set of dummies if booting emulator.
used to be autoexec.bat
           autoexec.emu
           config.sys
           config.emu
all resided in msdos live boot partition. live boot used normal and
emulator boot used .emu setups.  used to be.

if it helps:  I have a minimum of 5 keyboards (seats) that I run daily
(except when I can escape) and most of them have multiple hard drives.
On the systems I use most - I have multiple hard dirves. One for Win98,
one for MSDOS 6.22, one for Linux, one for xtra dos storage, big ones
for Linux storage, one or two for Solaris. Most keyboards are multiboot.
Sometimes I need a program that is only available on a specific OS, so
I boot that OS and run native. Sometimes I envoke DOSEMU and do
something
like a dBASE run. Sometimes I envoke WINE and creep through the process
because my stopwatch has confirmed that is faster than rebooting, doing
it and rebooting back to Linux. 
DOSEMU still works on other systems here. Just refuses to get it in gear
on my personal laptop. It will. If I have to re-write it - it will.
Bet on that.

I regularly do a dBASE thing. Complicated - we will call it a "thing".
In live boot MSDOS it can and does take hours to run.
One run in particular was timed. 6 hours.
Then I booted Linux, started 1.0.2.? and - on same hardware, same disk,
using same program and same data set ran it again.  right at 20 minutes.

If you need another excuse to keep going - I've got a baseball bat. :)


> 
> >       2) need to put himem and UMB back into operation. 1.1.99.1 reduced
> >               available memory considerably. (canceled compress.exe use)
> 
> you'll have to elaborate on that. These two are active by default if you
> use DOS=UMB,HIGH which is in the default config.sys.

nope - not in the 1.1.99.1 pre-compiled. everything loads "low".

> 
> MEM reports 628K (642,640 bytes) free, and 108K (110,224 bytes) free upper
> memory in xdosemu.
> 
try 528 free and 0 use of upper.

> Bart
========================================

Steve Turner
norseman@firstlight.net

Re: 1.2.0 binary install

[Jan Willem Stumpel]

Ged Haywood wrote:

> Actually I dislike the verbosity,
My point was that I think *dummies* like the verbosity. If you are
a dummy, then of course I am mistaken.

> but 'v' option or not, the tar manpage on my boxes says: [..]
Linux as a whole (not only dosemu) suffers from incredibly bad
documentation. xfzv works, and has worked for years, in any
permutation.

> Sounds like time to send in a documentation patch. I tell you
> what.  You write it, I'll test it.  Deal?
You never (as you said) even tried the binary install. Some
tester! But I did. Let's do it the other way round: you make it
work (including the font part), then I write the doc. Deal?

Seriously: I think the binary install should do exactly the same
that the (excellent) source install does; i.e. it should put
exactly the same files in exactly the same locations (/usr/local)
that are used by ./configure, make, [become root] make install. It
should just free the dummy user from the compilation step, for
which he/she most probably lacks the tools, and would be
confronted with (to her/him) incomprehensible error messages
because of that. It should (like the source install) also be
independent of freedos, because dosemu itself is independent of
it. Like the source install, it should ask which directory is the
'C drive'. If user/dummy does not know, it should be pointed out
that some form of DOS is needed, and installation of freedos offered.

> PS: Do you always send UTF-8?
In principle, yes.. but in Mozilla, apostrophes often behave
weirdly, don't quite understand why. ASCII is supposed to be valid
UTF-8. 'Send'? '73'? Radio?

Regards, Jan

Re: 1.2.0 binary install

[Bart Oldeman]

On Fri, 23 Jan 2004, Jan Willem Stumpel wrote:

> Seriously: I think the binary install should do exactly the same
> that the (excellent) source install does; i.e. it should put
> exactly the same files in exactly the same locations (/usr/local)
> that are used by ./configure, make, [become root] make install. It
> should just free the dummy user from the compilation step, for
> which he/she most probably lacks the tools, and would be
> confronted with (to her/him) incomprehensible error messages
> because of that.

In that case the RPM install is more appropriate. Seriously when I created
the RPM I was wondering if I should still provide the tarball; in general
users vote with feet so I put it up for rc1 and watched the statistics.

For 1.1.99.1 we have from SF
http://sourceforge.net/project/showfiles.php?group_id=49784
RPM            : 9490 downloads
Source RPM     : 2906
binary tarball : 3976
source tarball : 7148
source patch   :  435

So it looks like the RPM is the most popular, but there is still
significant demand for the binary tarball.

The point about the binary tarball (as Hans Lermen explained it, as far
as I know) is that you can quickly and easily check out DOSEMU in your
home directory *without needing root*. He thought building RPMs, deb's and
so on was a job for distributors (many of them who get paid for just doing
that after all, and we don't...)

But.. DOSEMU isn't as important anymore as it used to be and some
distributions no longer have it.

For instance, for Red Hat versions:
6.0 (Apr 99) and all previos Red Hats had it in base (DOSEMU 0.99.10)
6.1 (Sep 99) also (ver 0.99.13)
6.2 (Feb 2000) moved it to the extras in "powertools" (0.99.13)
7.0 (Aug 2000) powertools (1.0.1)
7.1 (Mar 2001) powertools (1.0.1)
7.2 (Sep 2001) dropped it and Bernhard Rosenkraenzer maintained the
previous RH rpm privately.

DOSEMU 1.0.2 (the one where the binary tarball was introduced) was
released in June 2001.

> It should (like the source install) also be
> independent of freedos, because dosemu itself is independent of
> it.

I don't agree with that completely; that's why I included FreeDOS in the
rpm. The point of the RPM is to be able to:

rpm -i dosemu-1.2.0-1.i386.rpm
xdosemu
and it just works after answering a few questions. As part of those
questions the user may point to another DOS if he wants to but he should
be able to just press [Enter] a couple of times and it just works.

If another DOS is used; yes it's a bit of a waste of bandwidth but that's
the price you pay. And anyways many programs (think about mozilla!) are
much much larger than the 2MB DOSEMU rpm.

Debian users could use alien (or just get the Debian package from Debian;
1.2.0 is in sid now).

So -- perhaps your DOSEMU for dummies page should point to the RPM
instead?

Anyway, i would welcome any documentation updates! There are even a few
things on the web you could look at, e.g.
http://www.wordstar2.com/dos6steps.htm
http://www.linux2000.com/stsplus-linux.html
http://www.rkka.org/Campaigns/dehowto.htm
http://www.rkka.org/Campaigns/lindosfaq.htm
http://ostrab2.potsdam.edu/CIS310/mydos/install.html
http://www.linuxandmain.com/modules.php?name=News&file=article&sid=363
"is the bee's knees as far as installation goes" -- can't be _that_
difficult then ;)

About the font problem. I honestly don't know what is going on. Between
rc1 and rc2 I added some attempts to desperate get xset +fp ... working
but apparently there's still something broken, but only for some people;
for me it can find the font just fine. Seems to depend on the X server
configuration. But I honestly don't know... I just can't reproduce.

Bart

Re: 1.2.0 binary install

[Ged Haywood]

Hi Jan,

On Fri, 23 Jan 2004, Jan Willem Stumpel wrote:

> > Actually I dislike the verbosity,
> My point was that I think *dummies* like the verbosity. If you are
> a dummy, then of course I am mistaken.

Well we'll agree to differ on that point.  Or those points.  :)

> > but 'v' option or not, the tar manpage on my boxes says: [..]
> Linux as a whole (not only dosemu) suffers from incredibly bad
> documentation. xfzv works, and has worked for years, in any
> permutation.

Well we'll agree to agree on at least some of those points.

> > Sounds like time to send in a documentation patch. I tell you
> > what.  You write it, I'll test it.  Deal?
> You never (as you said) even tried the binary install. Some
> tester!

Well that was the idea - no preconceived ideas, see? :)

> But I did. Let's do it the other way round: you make it
> work (including the font part), then I write the doc. Deal?

Heck, no.  I like to read the book and just do what it says.
Maybe I'm just lazy.  Or a dummy.  Or both.

> Seriously: I think the binary install should do exactly the same
> that the (excellent) source install does

Well we can agree on that entirely.  Unfortunately I'm not sure it's
very easy given the rich texture of the various flavours of Unix-like
operating systems.  Or the big mess as some would call it.

> > PS: Do you always send UTF-8?
> In principle, yes.. but in Mozilla, apostrophes often behave weirdly

Mozilla?  I'm using Pine.  Eight bits has always been enough for me.

> 'Send'? '73'? Radio?

A long time ago.  It's all 2.4GHz now, kids' stuff.

73,
Ged.
MSEG3

Re: 1.2.0 binary install

[Justin Zygmont]

> Seriously: I think the binary install should do exactly the same
> that the (excellent) source install does; i.e. it should put
> exactly the same files in exactly the same locations (/usr/local)
> that are used by ./configure, make, [become root] make install. It
> should just free the dummy user from the compilation step, for
> which he/she most probably lacks the tools, and would be
> confronted with (to her/him) incomprehensible error messages
> because of that. It should (like the source install) also be
> independent of freedos, because dosemu itself is independent of
> it. Like the source install, it should ask which directory is the
> 'C drive'. If user/dummy does not know, it should be pointed out
> that some form of DOS is needed, and installation of freedos offered.

well, a compresed tar file will extract itself relative to your current 
path, so you can't really have it install to /usr/local by default, it's 
not usually a problem anyways.  There is the RPM that might be preferrable 
for you, dosemu is much easier than it used to be.  

Re: 1.2.0 binary install

[Bart Oldeman]

On Fri, 23 Jan 2004, norseman wrote:

> As long as things are getting cleaned up:
> 	I suppose it makes one think their project is bigger if they
> scatter it out all over the damn place. But I suggest something like:
> 		$HOME/.dosemu 	       drives/and user's config and such
> 		/usr/local/dosemu      EVERYTHING else
> If having a hundered directories makes one feel more important, or just
> not able work without them, have at it in this one spot.

The FHS would actually favour /opt/dosemu instead of /usr/local/dosemu in
this case. But this is problematic for several reasons:
* you'd have to add something like /usr/local/dosemu/bin to your PATH
  (otherwise a simple "dosemu" wouldn't work)
* you'd have to add something like /usr/local/dosemu/man to your MANPATH
  (otherwise "man dosemu" wouldn't work)
so this is why "make install" puts most things in /usr/local/share/dosemu,
and only the binaries, manpages, and documentation in other places.

> BIG NOTE:
> 	MSDOS itself does not support record or file locking.

this is wrong: it sure does! MSDOS has had to deal with network drives for
many years, since version 3.0. That's one of the reasons why the DOS
"SHARE" command exists.

> Linux does and DOSEMU.bin can enforce.

dosemu.bin tries to emulate file locking; if DOS tries to lock a file,
then Linux tries to lock it. The main trouble is that these interfaces are
horribly incompatible; it'll probably work but there are exceptions.

> Applies to /usr/local/dosemu/freedos and actual MSDOS partitions.
> exception:  if a $HOME/freedos is used.  Then each user would have
> his/her own dos world and locks would not apply.

/usr/local/share/dosemu/freedos is usually readonly (except for root).
Actual MSDOSpartitions or anything else that is writable are like network
drives. DOS applications that must care about locking already have done
so for many years. So I'm not sure what you're up to here.

Bart

Re: 1.2.0 binary install

[Bart Oldeman]

On Fri, 23 Jan 2004, norseman wrote:

> I suspect all the RPM people got together and padded the count.

wow. Conspiracy theory. We love that right ;)

> The more I see and use of RPM the less I like it.
> It is a potential security risk.  Please don't go there.

RPM was selected by the people at www.linuxbase.org (LSB) as the standard
binary distribution format. These are knowledgeable people. If RPM were a
real security risk it wouldn't have been selected.

> speaking of adding things:
> 	1) pre-compiles need to actually read a config file and accept
> 		.emu extensions instead of ignoring them.

what do you mean here? $_emusys in dosemu.conf?

> 	2) need to put himem and UMB back into operation. 1.1.99.1 reduced
> 		available memory considerably. (canceled compress.exe use)

you'll have to elaborate on that. These two are active by default if you
use DOS=UMB,HIGH which is in the default config.sys.

MEM reports 628K (642,640 bytes) free, and 108K (110,224 bytes) free upper
memory in xdosemu.

Bart

Re: 1.2.0 binary install

[Bart Oldeman]

On Fri, 23 Jan 2004, norseman wrote:

> again:  /usr/local/share/dosemu  is just more typing.
>         /usr/local/dosemu        see?

I know, but I'm trying to follow a standard, the FHS, which may be
different from the norseman standard.

> MSDOS does not do network.

it sure does. Think about multiple DOSEMUs running at the same time as
multiple DOS clients sitting on a LAN. The lredir'ed drives look to DOS
and DOS applications as network drives. Nothing more and nothing less.

> YES - 1.0.2 and 1.1.99.1 do require a disk partition to be dismounted
> before they run.

that's *direct* partition access you are talking about. And yes,
for that ($_hdimage = "/dev/hda1") you need exclusive access, otherwise
the FAT will be corrupted.

The method of
linux# mount /dev/hda1 /dosc
c:\>lredir c: linux\fs/dosc
is completely different. Now c: is a network drive to DOS apps. And
locking may or may not be used by those applications. Just like Linux apps
may or may not use locking techniques.

> Xtreegold, dBASE III+ WordStar 4 and a ton of other software I run on
> MSDOS have absolutely no concept of file locking. And never did.

dBASE III+, Clipper, FoxPro, and many others have a concept of file
locking and use it more or less extensively. See int21/ah=3d, modes for AL
(DENYALL, DENYWRITE, DENYREAD, DENYNONE) and int21/ah=5c.

> Past tense used because recompiles of 1.0.2 and 1.1.99.1 fail to
> function
> on new hardware. Same OS, same install - new laptop. Fail Totally.

That's the famous 2.6.1 kernel problem most likely. $_mapping="mapfile"
would solve it. DOSEMU 1.2 has a workaround (runtime check).

> Traditionally:
> 	In UNIX
> 		/bin /sbin and such are OS system files
> 		/usr/bin /usr/sbin and such are login's files
> 		/usr/local/bin /usr/local/sbin and such
> 			are files specific to local hardware and console use.
> 			like cdrecord (you know how - get the image onto
> 			a local drive, drop the net, make the burn and
> 			restart the net. Or have lots of coasters.)

according to FHS:

/bin : Essential user command binaries (for use by all users)
/sbin : System binaries
/usr/bin : Most user commands
/usr/sbin : Non-essential standard system binaries
(nothing to do with login --bo)
The /usr/local hierarchy is for use by the system administrator when
installing software locally.  It needs to be safe from being
overwritten when the system software is updated.  It may be used for
programs and data that are shareable amongst a group of hosts, but not
found in /usr. Locally installed software must be placed within
/usr/local rather than /usr unless it is being installed to replace
or upgrade software in /usr

       4.9.2  Requirements
       The following directories, or symbolic links to directories, must be in
       /usr/local
       /usr/local -- Local hierarchy
       +-bin       Local binaries
       +-games     Local game binaries
       +-include   Local C header files
       +-lib       Local libraries
       +-man       Local online manuals
       +-sbin      Local system binaries
       +-share     Local architecture-independent hierarchy
       +-src       Local source code
       No other directories, except those listed below, may be in /usr/local
       after first installing a FHS-compliant system.

Bart

Re: 1.2.0 binary install

[Bart Oldeman]

On Fri, 23 Jan 2004, norseman wrote:
> Bart Oldeman wrote:

> > what do you mean here? $_emusys in dosemu.conf?
>
> no;   .emu extensions to autoexec and config so one doesn't have
> to continually copy dummies to .bat .sys if booting live and
> another set of dummies if booting emulator.
> used to be autoexec.bat
>            autoexec.emu
>            config.sys
>            config.emu
> all resided in msdos live boot partition. live boot used normal and
> emulator boot used .emu setups.  used to be.

right that's what's $_emusys does: use $_emusys="emu" and dosemu will use
config.emu instead of config.sys. Put
 SHELL=COMMAND.COM /P /K AUTOEMU.BAT
in config.emu to execute something else than autoexec.bat.

> Then I booted Linux, started 1.0.2.? and - on same hardware, same disk,
> using same program and same data set ran it again.  right at 20 minutes.

sure, Linux is good at disk caching ...

> > you'll have to elaborate on that. These two are active by default if you
> > use DOS=UMB,HIGH which is in the default config.sys.
>
> nope - not in the 1.1.99.1 pre-compiled. everything loads "low".

not a dosemu problem I think. May have to do with config.emu stuff above;
just put that DOS=HIGH,UMB in your config.sys and you'll get your UMBs and
HMA.

Bart

Re: 1.2.0 binary install

[norseman]

Bart Oldeman wrote:
> 
> On Fri, 23 Jan 2004, norseman wrote:
> 
> > again:  /usr/local/share/dosemu  is just more typing.
> >         /usr/local/dosemu        see?
> 
> I know, but I'm trying to follow a standard, the FHS, which may be
> different from the norseman standard.
> 

I guess the questions are: Why follow any "Jonhhy come lately"?
	Why not keep it simple, to the point and traditional?

> > MSDOS does not do network.
> 
> it sure does. Think about multiple DOSEMUs running at the same time as
> multiple DOS clients sitting on a LAN. The lredir'ed drives look to DOS
> and DOS applications as network drives. Nothing more and nothing less.
>

NO IT DON'T. IT NEVER DID. There were/are "add-ons" that alow network,
but MSDOS as shipped by MicroSoft NEVER had network buit-in. Truth!
Your version might, but MSDOS doesn't.
 
> > YES - 1.0.2 and 1.1.99.1 do require a disk partition to be dismounted
> > before they run.
> 
> that's *direct* partition access you are talking about. And yes,
> for that ($_hdimage = "/dev/hda1") you need exclusive access, otherwise
> the FAT will be corrupted.
>

Daffynition time:
	 live boot = booting the actual OS
         use real MSDOS 6.22 bootable disk = that's *direct* partition
access

"otherwise the FAT will be corrupted."
 S O C K S (pronounce the letters and you say the mexican equivelant of
             That is what I said.
           )  

> The method of
> linux# mount /dev/hda1 /dosc
> c:\>lredir c: linux\fs/dosc
> is completely different. Now c: is a network drive to DOS apps. And

In REAL MicroSoft_Disk_Operrating_System (MSDOS) use, having C: appear
as a network drive disables a ton of software. Most Norton 4.x disk
utilities (DS- directory sort, NU- direct disk util, etc) will refuse
to run.

I guess it's time to ask: 
	What are you maintaining? Is it supposed to be the ability
to run actual MS-DOS as it was when it was *the* OS or something else?

	As concerns: that's *direct* partition access:
	The use of DOSEMU_1.0.2.? on older hardware and Slackware 8.1
and earlier yielded full MS-DOS compatibility (as far as I tested) on
all but protected mode programs (like AutoCAD). Would you please define
your vision of your current and projected DOSEMU efforts?
(I never tried it on Slack 9.0 or 9.1)

	What do you consider DOSEMU to be?

	What is FHS?  (I see the layout, FHS is F___ H____ S___
			fill in the blanks please.
		      )

	If FHS is interested in turning the world upside down,
	Why should I (or anyone) follow? 

I'm not mad, just concerned (and a bit confused).
	Where are your defined objectives for DOSEMU?

Steve Turner
norseman@firstlight.net

Re: 1.2.0 binary install

[Ged Haywood]

Hi all,

On Sat, 24 Jan 2004, Bart Oldeman wrote:

> > Then I booted Linux, started 1.0.2.? and - on same hardware, same disk,
> > using same program and same data set ran it again.  right at 20 minutes.
> 
> sure, Linux is good at disk caching ...

And it can use a few gigabytes.  DOS has trouble with that much.

Our three-monthly product price update used to take four hours under
DOS.  That could be a real bitch, especially at Christmas, because we
would usually end up doing it again and again until we'd weeded out
most of the little surprises that our suppliers put in there for us.

Last Christmas under Linux it took 1 minute 28 seconds.

73,
Ged.

Re: 1.2.0 binary install

[Jan Willem Stumpel]

Bart Oldeman wrote:

> But.. DOSEMU isn't as important anymore as it used to be and
> some distributions no longer have it.
Shame on them! I suppose it is inevitable as newer generations of
computer users have never heard of DOS.

> If another DOS is used; yes it's a bit of a waste of bandwidth
> but that's the price you pay. And anyways many programs (think
> about mozilla!) are much much larger than the 2MB DOSEMU rpm.
No, I am not worried about the bandwidth, it's probably more my
feeling that the dosemu C drive should be set up in a user's home
directory with its own DOS in it.

> 1.2.0 is in sid now.
Thanks for the tip! This must have happened in the last few days.
Pity that the Debian version does not have this handy
~/.dosemu/drives directory. In the RPM, apparently, there is a
drives directory, but it is in /etc. I think it should be in the
user´s home directory.

> So -- perhaps your DOSEMU for dummies page should point to the
> RPM instead?
I closed the page quite a while ago but received a resurrection
request recently, so the old version is back temporarily. I think
I am going to make a new version now I know how to make the binary
distribution work (see below). And of course I will point to the
RPM and also the .deb.

> About the font problem. I honestly don't know what is going on.
> Between rc1 and rc2 I added some attempts to desperate get xset
> +fp ... working but apparently there's still something broken,
> but only for some people; for me it can find the font just
> fine. Seems to depend on the X server configuration. But I
> honestly don't know... I just can't reproduce.
I also messed about a lot with xset, xfontsel, xlsfonts but
nothing helped. But I could finally make it work by changing
Xfonts/fonts.dir in the binary distribution (it is generated the
first time that xdosemu runs). Replaced the line

vga.pcf vga

with

vga.pcf -dosemu-vga-medium-r-normal--17-160-75-75-p-80-ibm-cp437

No idea why this is necessary. I haven't a clue about how X works.
Of course I don't know if this breaks other (non-Debian?) setups,
but if it does not, fonts.dir should perhaps be included in the
distribution.

Regards, Jan




-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 1.2.0 binary install

[Bart Oldeman]

On Sat, 24 Jan 2004, Jan Willem Stumpel wrote:

> No, I am not worried about the bandwidth, it's probably more my
> feeling that the dosemu C drive should be set up in a user's home
> directory with its own DOS in it.

that's what the "dosemu" script does (optionally) -- it sets up a bunch of
symbolic links and a private copy of config.sys/autoexec.bat.

> > 1.2.0 is in sid now.
> Thanks for the tip! This must have happened in the last few days.
> Pity that the Debian version does not have this handy
> ~/.dosemu/drives directory. In the RPM, apparently, there is a
> drives directory, but it is in /etc. I think it should be in the
> user´s home directory.

the /etc/dosemu/drives/c symlink in the RPM acts as a systemwide and
backup symlink.

it's what is used if the user answers "none" to this question:

  Going to install your private DOSEMU-freedos files into the directory
  $HOME/dosemu
  Enter an empty string to confirm, a new path (the files will then
  be installed in a subdirectory named "dosemu" under that new path),
  or "none" (without the quotes) if you don't want a writable
  C-drive.

Essentially DOSEMU looks for boot directories and hdimages under
~/.dosemu/, then in /etc/dosemu, and then in /var/lib/dosemu.

The Debian config is just the same as it was in Debian's dosemu 1.0.2.1 --
I suppose Herbert Xu couldn't be bothered to change a lot again. It's
always been a little different from what "make install" (or
"./install_systemwide" when "make install" didn't work) did.
Whatever is better is so much a question of taste that I don't want to go
into that debate now :)

> > About the font problem. I honestly don't know what is going on.
> > Between rc1 and rc2 I added some attempts to desperate get xset
> > +fp ... working but apparently there's still something broken,
> > but only for some people; for me it can find the font just
> > fine. Seems to depend on the X server configuration. But I
> > honestly don't know... I just can't reproduce.
> I also messed about a lot with xset, xfontsel, xlsfonts but
> nothing helped. But I could finally make it work by changing
> Xfonts/fonts.dir in the binary distribution (it is generated the
> first time that xdosemu runs). Replaced the line
>
> vga.pcf vga
>
> with
>
> vga.pcf -dosemu-vga-medium-r-normal--17-160-75-75-p-80-ibm-cp437

hmm, yes that could be it! And now I see why: the vga.pcf in the source
install and in the rpm in generated dynamically (using bdftopcf from
vga.bdf) but the one in the bindist is still simply copied from the old
vga.pcf in etc/ in the source (which should be deleted really).

-- if you copy the installed vga.pcf.gz to your Xfonts dir and then run
mkfontdir it will just go fine. Time to correct this bug. Thanks for
nailing it down.

Bart

-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 1.2.0 binary install

[norseman]

Justin Zygmont wrote:
> 
> > NO IT DON'T. IT NEVER DID. There were/are "add-ons" that alow network,
> > but MSDOS as shipped by MicroSoft NEVER had network buit-in. Truth!
> > Your version might, but MSDOS doesn't.
> 
> i remember msdos 6 had it, they removed it after
> 
>

I checked the shelf. I have 3.2 but am missing rest of 3.x and part 
of 5.x series too. I remember not liking 6.1 so I tossed that. Went to
6.2 and 6.22 (which I still use). I don't have a 6.0 so I take your word
on that and I stand corrected.

Steve Turner
norsman@firstlight.net

Re: 1.2.0 binary install

[Jan Willem Stumpel]

Bart Oldeman wrote:

> that's what the "dosemu" script does (optionally) -- it sets up
> a bunch of symbolic links and a private copy of config.sys/
> autoexec.bat.

So you set some kind of option on running the script? [at this
point I thought of trying man dosemu]. I tried xdosemu -install
~/mytestdos but that does not work. Got some kind of help screen
which did not mention the -install option talked about by man dosemu.

> the /etc/dosemu/drives/c symlink [..] is used if the user 
> answers "none" to this question:

I´m sorry, I did not actually install and run the rpm, just looked
inside it. If questions are asked during the install, offering a
writable C drive, that is of course just fine. The Debian package
does not do it. OK.. I´m now going to try to actually install the
rpm (using "alien").

> Essentially DOSEMU looks for boot directories and hdimages 
> under ~/.dosemu/, then in /etc/dosemu, and then in 
> /var/lib/dosemu.

OK.. that clears it up.

Regards, Jan


-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 1.2.0 binary install

[Bart Oldeman]

On Sat, 24 Jan 2004, Jan Willem Stumpel wrote:

> Bart Oldeman wrote:
>
> > that's what the "dosemu" script does (optionally) -- it sets up
> > a bunch of symbolic links and a private copy of config.sys/
> > autoexec.bat.
>
> So you set some kind of option on running the script? [at this
> point I thought of trying man dosemu]. I tried xdosemu -install
> ~/mytestdos but that does not work. Got some kind of help screen
> which did not mention the -install option talked about by man dosemu.

What did the "some kind of help screen" say exactly?

The -install option works differently for the dosemu script that is part
of the binary tarball than for the one in the RPM or created by make install.

The binary-tarball-dosemu works on the assumption that dosemu.bin lives
~/.dosemu/drives/c/../bin -- that's why its "install" isn't as flexible
and it doesn't need to ask questions.

The RPM/"make install" dosemu has the position of dosemu.bin hardcoded in
the script (e.g. /usr/bin/dosemu.bin or /usr/local/bin/dosemu.bin).

Bart

Re: 1.2.0 binary install

[Justin Zygmont]

> NO IT DON'T. IT NEVER DID. There were/are "add-ons" that alow network,
> but MSDOS as shipped by MicroSoft NEVER had network buit-in. Truth!
> Your version might, but MSDOS doesn't.

i remember msdos 6 had it, they removed it after

Re: 1.2.0 binary install

[Bart Oldeman]

On Sat, 24 Jan 2004, norseman wrote:

> Bart Oldeman wrote:
> > On Fri, 23 Jan 2004, norseman wrote:
> > > MSDOS does not do network.
> >
> > it sure does. Think about multiple DOSEMUs running at the same time as
> > multiple DOS clients sitting on a LAN. The lredir'ed drives look to DOS
> > and DOS applications as network drives. Nothing more and nothing less.
> >
>
> NO IT DON'T. IT NEVER DID. There were/are "add-ons" that alow network,
> but MSDOS as shipped by MicroSoft NEVER had network buit-in. Truth!

"does not do" is a very broad statement. "OS" is very broad. What I was
thinking of is "you can network with DOS systems", not so much "the DOS
kernel supplies networking". The truth is that the DOS kernel (MSDOS,
DRDOS, FreeDOS, ...) has hooks ("redirector interface") that can be
connected to network TSRs. These hooks are explicitly designed (better
said "hacked") to talk to networks. That's how I meant "DOS supports (not
supplies) networking".

> "otherwise the FAT will be corrupted."

multiple DOSEMUs directly accessing partitions at the same time is a sure
recipe for disaster. Do it via lredir and things can go very well indeed.

> > The method of
> > linux# mount /dev/hda1 /dosc
> > c:\>lredir c: linux\fs/dosc
> > is completely different. Now c: is a network drive to DOS apps. And
>
> In REAL MicroSoft_Disk_Operrating_System (MSDOS) use, having C: appear
> as a network drive disables a ton of software. Most Norton 4.x disk
> utilities (DS- directory sort, NU- direct disk util, etc) will refuse
> to run.

sure. but I have no interest in running Norton diskedit most of the time
in DOSEMU. There are Linux disk editors too.

> I guess it's time to ask:
> 	What are you maintaining? Is it supposed to be the ability
> to run actual MS-DOS as it was when it was *the* OS or something else?

Running MS-DOS or FreeDOS doesn't matter. Not having to reboot to run DOS
applications does.

See for example if I'm hacking the FreeDOS kernel I can
* have the source files (which all live on an ext3 partition) open with
  Emacs in Linux, can be checked in with CVS, and so on.
* have one dosemu (in dumb mode) compiling the bunch with handy xterm
  backscrolling
* one dosemu session is for testing. FreeDOS kernel compiled -- costs 2
  seconds to reboot a new one.
* without disturbing the session I can inspect and debug the session with
  dosdebug
* and, as a bonus, I could do all this remotely via ssh for instance
* and at the same time easily watch email, surf the net, do other stuff
  and fire up another xdosemu to play a nice old DOS game with full sound
  support.

you see, dosemu enables you to do things with DOS that native DOS could
never dream about... on my laptop there isn't even a FAT partition (only
an image for testing) and yet I can run almost all DOS programs easily.

> 	What is FHS?

www.google.com type FHS in the box, click "i'm feeling lucky".

Bart