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
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
