Mail Archives: opendos/2001/02/12/22:26:13
See below ...
Joe.
> -----Original Message-----
> From: Patrick Moran [SMTP:pmoran22 AT yahoo DOT com]
> Sent: Tuesday, 13 February 2001 11:18
> To: opendos AT delorie DOT com
> Subject: Re: DR-MOUSE, DPMS (was Hard Disk 20gb and dos)
>
>
> ----- Original Message -----
> From: "da Silva, Joe" <Joe DOT daSilva AT emailmetering DOT com>
> To: <opendos AT delorie DOT com>
> Sent: Monday, February 12, 2001 4:07 PM
> Subject: RE: DR-MOUSE, DPMS (was Hard Disk 20gb and dos)
>
>
> > The best way to load DRMOUSE is to *not* try to load it
> > high. Install (run) it in conventional (lower) memory and it
> > will load it's resident portion high, all by it's clever little self.
> > That way, you just need about 7K (IIRC) free in the HMA
> > to load it high, nothing extra for the initialization code ...
>
> Actually, I don't use any LOADHIGH, HILOAD, or LH in any of the DRDOS
> TSRs/Drivers. I let them all do their own thing. But you made a slight
> mistake there, DRDOS DRMOUSE does not load into HMA, it loads into upper
> memory.
>
[da Silva, Joe]
Oops! You're quite right - I should have said UMB, not HMA.
This Intel cr*p is a right confusing mess, isn't it?! :-/
Incidentally, I mentioned the above because you seemed
to be saying you used QEMM to load DRMOUSE, so I
thought you meant QEMM's equivalent to 'LH' ...
> Oooops, I'll take that back a little. I do not normally load DRMOUSE. If
> I want it loaded, I just type DRMOUSE and let it load EXECPT when I use
> Task Manager and intend to use the modem for communications. In that
> case I force it to load low in each window that I wish to use it, and
> then unload it before ending a task using it. This is not just a problem
> unique to DRMOUSE. I have yet to find any mouse driver that can be
> loaded high and not mess with the communications of the modem when I
> switch that task to the background. It just halts the data flow.
>
[da Silva, Joe]
Don't know about that ... I never did get multitasking to work
properly, so I never had this problem ... :-/
> Also I will firce some things to load low when using Personal Netware to
> get the most use of upper memory. I let VLM do it's thing but paly with
> the rest such as LSL.COM. The DRDOS memory manager is not too
> intelligent (like QEMM is) and I have to play around with the small
> drivers and TSRs to get the best results when using the server. The
> client does not take that much. However, DRDOS memory manager is a lot
> smarter than MSDOS's.
>
[da Silva, Joe]
Why not use Novell's 32 bit drivers, instead? They load into
extended memory, so you can load lots more goodies into
the UMB ...
> > Given that DPMS has been mentioned a few times
> > recently (wrt. NWCACHE and NWCDEX), it reminds me
> > that we have not come to a conclusion about the
> > following (discussed several weeks ago) :
> >
> > 1. We established that the versions of DPMS.EXE that
> > could be freely distributed with client programs were
> > the OpenDOS 7.01 and the Novell DOS versions. So,
> > which is the best of these two versions to use?
>
> Did anyone actually contact Lineo about this? Since it is not a major
> upgrade, I don't see how they can change Novell's policy on this. They
> would have had to purchase the license intact and since Novell made it
> freely available to anyone, I don't see how Caldera/Lineo can/could
> change it. If it were version 7.1 or something, maybe they could.
>
[da Silva, Joe]
Yes ... well I have always been disappointed by
Caldera/Lineo. They have certainly never lived up
to their initial indications about where they would
take DR-DOS! Remember how the whole source
was going to be available? Remember the TCP/IP
stack, web browser, LFN and FAT32 support that
was promised?
IMHO, Caldera/Lineo's only real interest in DR-DOS
was to have something with which to sue Micro$oft.
Evidence :
Day 1 - Caldera acquires DR-DOS.
Day 2 - Caldera files it's suit against Micro$oft.
Day N - Caldera and Micro$oft settle.
Day N+1 - Cladera virtually stops DR-DOS development.
> > 2. Is there any problem (ie. bug) that we need to be
> > aware of, for whichever is the best version selected
> > above? (Sure - we ourselves would normally use a
> > later version (eg. from DR-DOS 7.02+/7.03), but
> > these cannot be freely distributed ...)
>
> I am not aware of any differences or bugs with any version. In fact I
> don't even know if any code has been changed other than Novell's
> updates, if there were any. I would have to look at the updated files
> and see if it is there. I don't recall ever replacing it. There probably
> is no difference from 7.00 and 7.01. Basically all 7.01 is, is Novell
> DOS 7.0 with all the upgrades and new updated kernel files. I don't
> think the even changed the copyright on the rest of the files. There may
> have been a couple of other changes, but I cannot recall the dates and
> details as to which was changed and when, but somewhere between Novell
> 7.0 original release and before 7.02, there were changes in NWCDEX. As I
> recall this was in update 14. The update was supposed to make it work
> with Terminate, but I never did get it to work with Terminate.
> Terminate has a hotkey (ALT-F10 as I recall) to play audio CD's while
> you were downloading files or idle in some other way. I never could get
> it to work with my SCSI CDROM. People who had IDE CDROMs reported that
> it worked. I am pretty certain that was in update 14.
>
> There was also an update for 7.02 to 7.03, I don't know if that version
> of DPMS is 7.02 or 7.03 or inbetween. I have all of these files stored
> on tape. I don't have any of the updates before 14, as each update
> contained all the files from previous updates except of course for files
> that were again updated such as the kernel files.
>
> Pat
>
>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
- Raw text -