ntvdm.exe replacement?

[Henry T Fiddler]

Hi ... not sure if these newsgroups have many dinasaurs like myself
going back into the 80's, but I just posted this at
microsoft.public.win3x_wfw_dos
and thought I'd try here also, to reach a wider audience. Here goes
...

-----------------------

Wow ... finally found a newsgroup with some fellow dinasaurs!

Before launching into my question, I would love any references to
great websites or other newsgroups to commiserate with fellow "legacy
dinasaurs". Just upgraded to Win XP Pro a month ago and would
appreciate some good company!

OK, now my question. Anyone got any ideas on this problem I'm
having?

Way back long long ago (like sometime in the early 80's), I got
addicted to this 16 bit DOS shareware "PC-Outline". Also, the old
Borland Turbo Pascal v3 editor. Oh yeah ... there was also Frank
Bell's Newkey (a shareware version of Prokey). Any of you remember
those good ole days???

Well, over the years, been porting from OS to OS, and managing to get
them all to work just fine up through and including Win 98 SE. I
knew the perverbial hatchet would fall sometime in the 1st decade of
the new millennium, and sure enough, with my recent leap into Win XP
Pro, it has happened, as I am learning all about ntvdm.exe these
days. :-(

Managed to get it all working, but the big gotcha is the way ntvdm
and its components write to the screen in a windowed mode. All is
fine and hunkey dorey if I go full screen (which is a pain). But in
an ntvdm emulated DOS window (with title bar, scroll bars, etc), I
end up with an annoying jerky scrolling. Some old 16 bit DOS apps
that used "video retrace" are a horror to behold (like trying to run
through 50 yr old molasses). This was the case with PC Outline until
I found out how to disable it. And Turbo Pascal appears to have no
way to disable video retrace. Another real pain is pasting from the
clipboard into a DOS window (via the control menu's Edit/Paste) with
the Video Retrace slowness. I get buffer overrun bigtime, tons of
speaker beeps, and gibberish on the screen. Very buggy Microsoft! I
found a workaround, which is very kludgy, inconvenient and painful,
which I won't bother explaining here, unless someone really needs it.

However even well behaved 16 bit DOS apps (like Microsoft's own
\window\system32\edit.com that comes with XP Pro), experience an
annoying jerky scrolling in a DOS window. I have tried on 3+ gHz
boxes and the speed of underlying processor makes no difference
whatsoever in the way this emulated display works. I have already
tried tweaking all the .PIF settings, with various priorities, etc.
and they have absolutely no effect.

So, I'm wondering if anyone else has observed this, and if there is
any known workaround or replacement?

Thanks all !!!
Henry Fiddler

 

[Linda]

Hi ... not sure if these newsgroups have many dinasaurs like myself
going back into the 80's, but I just posted this at
microsoft.public.win3x_wfw_dos
and thought I'd try here also, to reach a wider audience. Here goes
...

-----------------------

Wow ... finally found a newsgroup with some fellow dinasaurs!

Before launching into my question, I would love any references to
great websites or other newsgroups to commiserate with fellow "legacy
dinasaurs". Just upgraded to Win XP Pro a month ago and would
appreciate some good company!

OK, now my question. Anyone got any ideas on this problem I'm
having?

Way back long long ago (like sometime in the early 80's), I got
addicted to this 16 bit DOS shareware "PC-Outline". Also, the old
Borland Turbo Pascal v3 editor. Oh yeah ... there was also Frank
Bell's Newkey (a shareware version of Prokey). Any of you remember
those good ole days???

Well, over the years, been porting from OS to OS, and managing to get
them all to work just fine up through and including Win 98 SE. I
knew the perverbial hatchet would fall sometime in the 1st decade of
the new millennium, and sure enough, with my recent leap into Win XP
Pro, it has happened, as I am learning all about ntvdm.exe these
days. :-(

Managed to get it all working, but the big gotcha is the way ntvdm
and its components write to the screen in a windowed mode. All is
fine and hunkey dorey if I go full screen (which is a pain). But in
an ntvdm emulated DOS window (with title bar, scroll bars, etc), I
end up with an annoying jerky scrolling. Some old 16 bit DOS apps
that used "video retrace" are a horror to behold (like trying to run
through 50 yr old molasses). This was the case with PC Outline until
I found out how to disable it. And Turbo Pascal appears to have no
way to disable video retrace. Another real pain is pasting from the
clipboard into a DOS window (via the control menu's Edit/Paste) with
the Video Retrace slowness. I get buffer overrun bigtime, tons of
speaker beeps, and gibberish on the screen. Very buggy Microsoft! I
found a workaround, which is very kludgy, inconvenient and painful,
which I won't bother explaining here, unless someone really needs it.

However even well behaved 16 bit DOS apps (like Microsoft's own
\window\system32\edit.com that comes with XP Pro), experience an
annoying jerky scrolling in a DOS window. I have tried on 3+ gHz
boxes and the speed of underlying processor makes no difference
whatsoever in the way this emulated display works. I have already
tried tweaking all the .PIF settings, with various priorities, etc.
and they have absolutely no effect.

So, I'm wondering if anyone else has observed this, and if there is
any known workaround or replacement?

Thanks all !!!
Henry Fiddler

You'll get more posters reading a post if you're not so long winded about
what you're asking.

 

[cquirke (MVP Win9x)]

On 4 Sep 2004 02:15:17 -0700, (e-mail address removed) (Henry T

Way back long long ago (like sometime in the early 80's), I got
addicted to this 16 bit DOS shareware "PC-Outline". Also, the old
Borland Turbo Pascal v3 editor. Oh yeah ... there was also Frank
Bell's Newkey (a shareware version of Prokey).

Managed to get it all working, but the big gotcha is the way ntvdm
and its components write to the screen in a windowed mode. All is
fine and hunkey dorey if I go full screen (which is a pain). But in
an ntvdm emulated DOS window (with title bar, scroll bars, etc), I
end up with an annoying jerky scrolling.

This can be expected.

In full screen mode, DOS text apps write to display memory, either
directly, via BIOS calls, or via DOS calls. No matter which method is
used, the SVGA BIOS/chipset's own character set is used, and the
process is fast. Some "recent" DOS apps such as PC Tools 8 or Norton
Utilities 7 (don't try *that* in NT) redefined the SVGA text mode
character set to do prettier pseudo-graphics, e.g. box edged etc.

In windowed mode, all of those text writes are channeled through wads
of Windows drivers and some buffering (e.g. so that reads from display
memory will work) and that is not only very slow, but also uses the
Windows character set instead of that within the SVGA card. This also
breaks the look of apps that define custom character sets.

If you need such apps to run fast while still being able to "see" the
rest of Windows, I might suggest trying a dual-head SVGA card. If you
can run Windows on your "larney" screen and your DOS apps on an old
14" off the other SVGA port, that could be quite nice...

-------------- ---- --- -- - - - -

"I think it's time we took our
friendship to the next level"
'What, gender roles and abuse?'

 

[Henry T Fiddler]

You'll get more posters reading a post if you're not so long winded about
what you're asking.

Right ... and please stop wasting our time with your irrelevant
comments, so we all have more time to write accurate and detailed
descriptions of our problems. Also, I don't appreciate your hiding
behind <.@.>!

 

[Henry T Fiddler]

On 4 Sep 2004 02:15:17 -0700, (e-mail address removed) (Henry T

In windowed mode, all of those text writes are channeled through wads
of Windows drivers and some buffering (e.g. so that reads from display
memory will work) and that is not only very slow, but also uses the
Windows character set instead of that within the SVGA card. This also
breaks the look of apps that define custom character sets.

Very logical, and just what I would have thought .... HOWEVER ...

This explanation would lead one to believe that emulated display
performance would be highly sensitive to underlying processor speed.
Ie. faster processors should paint these Windows characters faster and
with less jerkiness than slower processors. However I have tried this
out on several boxes with widely varying speeds and the performance is
identical on all. It appears that the output is governed somehow to
the clock, so that we could run someday on 100 gHz boxes, and still
experience this same awful performance!

If you need such apps to run fast while still being able to "see" the
rest of Windows, I might suggest trying a dual-head SVGA card. If you
can run Windows on your "larney" screen and your DOS apps on an old
14" off the other SVGA port, that could be quite nice...

I have a laptop. I take it on the road and move it constantly. In
addition, I am convinced that this windowed video performance is
completely unrelated to processor speed, video ram, video card speed,
etc. It appears to be something inside ntvdm or one of it's related
driver modules.

Thanks for your insights. Any more?

 

[CS]

Right ... and please stop wasting our time with your irrelevant
comments, so we all have more time to write accurate and detailed
descriptions of our problems. Also, I don't appreciate your hiding
behind <.@.>!

You may not appreciate her hiding, but at least she's smart enough not
to use her real E-mail address and then cross post it to many groups.
You're just asking for SPAM and E-Mail viruses by using a real E-Mail
address. Of course then you'll probably complain to AT&T and say it's
their fault. But you'll keep on writing those accurate and detailed
descriptions of your problems......

 

[cquirke (MVP Win9x)]

"cquirke (MVP Win9x)" wrote

This explanation would lead one to believe that emulated display
performance would be highly sensitive to underlying processor speed.
Ie. faster processors should paint these Windows characters faster and
with less jerkiness than slower processors.

You'd think so, yes; I suspect part of the reason it doesn't, may have
to do with real-time slicing so that other tasks run at the same time.

When these old DOS apps were written, they generally avoided writing
text to screen via DOS or even BIOS services as these were "too slow".

Ironically, those optimizations become meaningless when Windows
emulates DOS apps; in fact, there may be more code required to emulate
a "direct" write to display memory than a DOS or BIOS call.

So although the processor is massively faster, there's considerably
more code involved. It still seems slower than I'd expect; perhaps
the impact is because the entire overhead is repeated for each
character that is written to the window.

However I have tried this out on several boxes with widely
varying speeds and the performance is identical on all.

That suggests real-time slicing at character-granularity.

Thanks for your insights. Any more?

Only as above, alas!

--------------- ----- ---- --- -- - - -

IRC is just multiplayer notepad.