From mboxrd@z Thu Jan 1 00:00:00 1970 From: norseman Subject: Re: 1.2.0 binary install Date: Fri, 23 Jan 2004 15:45:44 +0000 Sender: linux-msdos-owner@vger.kernel.org Message-ID: <401141A8.5D2E5425@firstlight.net> References: Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: List-Id: Content-Type: text/plain; charset="us-ascii" To: Bart Oldeman , linux-msdos@vger.kernel.org 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