- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Holland St.John: "Re: How Do I Identify My Microphone?"
- Previous message: John Nixon: "Re: L1 or L2 cache?"
- In reply to: L.C.Jackson@@psd.maff.gov.uk: "bring up Word file"
- Next in thread: Todd E. Scheresky: "Re: DD 3 and NT"
some component of it, is 16-bit; similarly if some component of
rapidSQL is also 16-bit. This sounds like programs stomping on each
other's memory space. This might happen if they are all sharing a DOS
process... as is apparently the case for 16-bit programs on NT.
A fellow named Paul Baclace rode through on a dark horse a few
days ago, and gave us some advice about 16-bit programs on NT, which I
append at the bottom of this message. He didn't say exactly how to do
it, try looking under Settings | System | Performance or something
like that... I don't have NT, so I can't check.
JF> -----Original Message-----
JF> From: Todd E. Scheresky [SMTP:tscheresky@@micron.com]
JF> Sent: Wednesday, March 11, 1998 6:19 PM
JF> To: jenny.woods@@rl.ac.uk
JF> Cc: jamie@@decisionism.com; dana@sybase.com
JF> Subject: Re: DD 3 and NT
[snip]
TS> DragonDictate's performance starts out quick and responsive, but in less
TS> than in one hour it's dragging. Worse yet since the application is a
TS> 16-bit application its memory is not protected and gets stopped on by
TS> other applications. For instance, if you use Pegasus Mail and simply
TS> download your mail from a POP server it screws up the word history
TS> commands. When you say "Oops", you can no longer say "Word 1", or
TS> "Choose 3". RapidSQL has the same effect on DragonDictate. Your only
TS> recourse is to restart DragonDictate, over, and over, and over again.
>>>>> "PEB" == Paul E Baclace <peb@@baclace.net> writes:
PEB> Regarding dragon dictate 3.x on NT4.0: because it still relies on
PEB> 16 bit code (I thought 3.0 was supposed to be fully 32 bit), it
PEB> is running under a DOS process on NT known as Windows on Windows
PEB> ("WOW"). Starting with NT4.0, the default WOW behavior changed
PEB> from "new DOS process each time" to "share single DOS process".
PEB> This was probably changed merely to save overall memory
PEB> consumption, but by sharing a single DOS process the effect of
PEB> memory leaks is worsened. If there are leaks in DOS code, then
PEB> changing your system to "new DOS process each time" should make
PEB> it possible to completely recover memory usage by quitting the
PEB> program involved. Under the default NT4.0 WOW behavior,
PEB> rebooting is necessary to clear up DOS related problems (unless
PEB> you kill the shared DOS process manually, which then kills all
PEB> DOS processes).
- Next message: Holland St.John: "Re: How Do I Identify My Microphone?"
- Previous message: John Nixon: "Re: L1 or L2 cache?"
- In reply to: L.C.Jackson@@psd.maff.gov.uk: "bring up Word file"
- Next in thread: Todd E. Scheresky: "Re: DD 3 and NT"
 |  |