Re: AW: Re: Friday OTT : DOS vs Windows performance

[CM Poncelet]

Thanks a lot for clarifying. Cheers, CP


Peter Hunkeler wrote:

AFAIK, windoze continually interrupts its execution to check whether the  
   

mouse has moved, whether a key has been hit (which would count as I/O or  
'graphics') or whether another has to be dispatched etc. 



Off the three above only the last is true. The mouse device and the keyboard 
device generate hardware interupts which interupt the processor. So Windows 
(and other OSs as well) don't need to poll, but are notified by the hardware.


Each time a key is pressed, or released, an interupt is generated. After the 
key is pressed, and that interupt has been generated, the keyboard repeatedly 
generates interupts as fast as the keyboard repeat rate tells is. The mouse 
generates upon mous button press and release. The mouse movement interupts are 
generated whenever the mouse has been moved a certain distance that depends on 
the mouse resolution.


The latter, mouse movement, it the most resource consuming of all the above. I 
remember well Solitair I used to play on Windows 95. The cards were jumping 
over the screen drawing nice pictures one you succeeded. The cards moved quite 
fast to present an nice animation. You could slow down, and even bring it to 
almost starve, when you moved the mouse fast and faster. That was a good 
visualization on how much resources supporting a mouse may consume.


--
Peter Hunkeler


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday OTT : DOS vs Windows performance

[Jack J. Woehr]

Richard Pinion wrote:

And who remembers DesqView


I ran DESQview. A nice 1985 joke. The Mac was already out.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday OTT : DOS vs Windows performance

[Richard Pinion]

Since we taking a walk down memory lane, my first DOS 
was MS-DOS 1.0, run on a Columbia Data Products luggable.

My first computer was a 16K, with expansion box, Timex
Sinclair.

And who remembers DesqView (I think that is how it was
spelled).  DesqView was described as a multi-window
multi-tasking environment.  I ran than on a 16 Mhz
8086 AT PC.



--- elardus.engelbre...@sita.co.za wrote:

From: Elardus Engelbrecht <elardus.engelbre...@sita.co.za>
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AW: Re: Friday OTT : DOS vs Windows performance
Date: Mon, 3 Oct 2016 06:48:33 -0500

Tom Brennan wrote:

>Peter Hunkeler wrote:
>> The latter, mouse movement, it the most resource consuming of all the above.

>That reminds me of around 1990 running Windows 3.0, when a newly-minted 
>Windows Admin (used to be a mainframer) saw my habit of moving the mouse in 
>big circles while waiting for the machine to repond.  She said I shouldn't do 
>that because I might crash the system.  I remember thinking to myself, "So 
>these machines are supposed to replace the mainframe?"

Haha. It reminds me of one or other software package (Cant remember the name) 
with a brand new part for handing rats, uh, mouses in a DOS screen. The 
previous version only worked with keyboard. 

That package worked more or less like FrameWork using EGA screen in DOS using a 
mix of mouse and keyboard.

But, if you drag the mouse pointer to the bottom edge of the screen, the system 
just hangs. If you're lucky, you can get control back after a while.

Apparently , some of the graphics of that pointer must be somewhere be visible 
on the screen. Pressing a shortcut command for say a menu item may bring the 
focus (and the mouse pointer) back on that menu item recovering a 'dead' / 
'unresponsive' system.

;-)

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




_
Netscape.  Just the Net You Need.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AW: Re: Friday OTT : DOS vs Windows performance

[Elardus Engelbrecht]

Tom Brennan wrote:

>Peter Hunkeler wrote:
>> The latter, mouse movement, it the most resource consuming of all the above.

>That reminds me of around 1990 running Windows 3.0, when a newly-minted 
>Windows Admin (used to be a mainframer) saw my habit of moving the mouse in 
>big circles while waiting for the machine to repond.  She said I shouldn't do 
>that because I might crash the system.  I remember thinking to myself, "So 
>these machines are supposed to replace the mainframe?"

Haha. It reminds me of one or other software package (Cant remember the name) 
with a brand new part for handing rats, uh, mouses in a DOS screen. The 
previous version only worked with keyboard. 

That package worked more or less like FrameWork using EGA screen in DOS using a 
mix of mouse and keyboard.

But, if you drag the mouse pointer to the bottom edge of the screen, the system 
just hangs. If you're lucky, you can get control back after a while.

Apparently , some of the graphics of that pointer must be somewhere be visible 
on the screen. Pressing a shortcut command for say a menu item may bring the 
focus (and the mouse pointer) back on that menu item recovering a 'dead' / 
'unresponsive' system.

;-)

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday OTT : DOS vs Windows performance

[Elardus Engelbrecht]

CM Poncelet wrote:

>Yes, the programs were written and meant to run natively - i.e. under native 
>DOS - and not in an emulated windoze DOS box.
>I was pointing out the horrendous overhead of running DOS programs under an 
>emulated windoze DOS box, instead of under their original native DOS.

This is WAD AFAIK, but could you try out DOSBox and see what is your programs 
performance there?

https://www.dosbox.com/ 
https://www.dosbox.com/wiki/

Have great fun with this DOSBox! ;-)

I can run all my ancient games (pre windoze) under that DOSBox including 
Ancient Art of War, Mean Streets, The Lost Vikings, etc. in my Windows 7 64 bit.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AW: Re: Friday OTT : DOS vs Windows performance

[Tom Brennan]

Peter Hunkeler wrote:
The latter, mouse movement, it the most resource consuming of all the above. 


That reminds me of around 1990 running Windows 3.0, when a newly-minted 
Windows Admin (used to be a mainframer) saw my habit of moving the mouse 
in big circles while waiting for the machine to repond.  She said I 
shouldn't do that because I might crash the system.  I remember thinking 
to myself, "So these machines are supposed to replace the mainframe?"


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Friday OTT : DOS vs Windows performance

[Peter Hunkeler]

>AFAIK, windoze continually interrupts its execution to check whether the
mouse has moved, whether a key has been hit (which would count as I/O or
'graphics') or whether another has to be dispatched etc.


Off the three above only the last is true. The mouse device and the keyboard 
device generate hardware interupts which interupt the processor. So Windows 
(and other OSs as well) don't need to poll, but are notified by the hardware.


Each time a key is pressed, or released, an interupt is generated. After the 
key is pressed, and that interupt has been generated, the keyboard repeatedly 
generates interupts as fast as the keyboard repeat rate tells is. The mouse 
generates upon mous button press and release. The mouse movement interupts are 
generated whenever the mouse has been moved a certain distance that depends on 
the mouse resolution.


The latter, mouse movement, it the most resource consuming of all the above. I 
remember well Solitair I used to play on Windows 95. The cards were jumping 
over the screen drawing nice pictures one you succeeded. The cards moved quite 
fast to present an nice animation. You could slow down, and even bring it to 
almost starve, when you moved the mouse fast and faster. That was a good 
visualization on how much resources supporting a mouse may consume.


--
Peter Hunkeler


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday OTT : DOS vs Windows performance

[CM Poncelet]

Thanks for that - yes, I know.

However, the ASM program uses only register and 'immediate', not 
storage-storage, instructions (RR and RI, but no RX and SS etc.) in its 
inner and outer loops  (LOOP2 and LOOP1). It does store/retrieve (PUSH, 
POP) data on the stack to save/retrieve intermediate data. It has no DOS 
instructions (e.g. INT 21H) inside the loops and uses no graphics. It is 
just OS independent Intel machine code and does not need to be 
'emulated'. Yet it takes approximately 100-200 times more CPU cycles to 
execute under windoze than under native DOS. (A 3.2GB Mhz processor is 
almost 100 times faster than a 33Mhz one.)


AFAIK, windoze continually interrupts its execution to check whether the 
mouse has moved, whether a key has been hit (which would count as I/O or 
'graphics') or whether another has to be dispatched etc. Native DOS is 
far more efficient performance-wise.


CP




Joel C. Ewing wrote:


On 10/01/2016 06:24 AM, Robert Prins wrote:
 


On 2016-10-01 01:59, CM Poncelet wrote:
   


't is Friday, so here we go again.

I wrote the following in Intel assembler in the 1990's to check the
CPU-cycles
performance of DOS vs Windows 3.1 (if memory serves), using a 486/33Mhz
processor and practically all executable code loaded in the
instruction cache:
 




   


This took approx 1'45" (elapsed) to execute under native DOS with a
80486/33Mhz
processor - i.e. there was a 1-to-1 correlation between the number of
machine
instructions vs the number of actual 33Mhz CPU cycles.

I reran this under Windows XP from the 'command prompt' with a 3.2Ghz
processor
(approx 100 times faster than a 33Mhz one), and it then took 3'48" to
complete -
thus about 200 times longer (CPU-wise/elapsed) than when running
under native DOS.

Moral: Use native DOS (preferably with a DOS extender) for fast PC
performance.
 


NO, NO, NO!!!

Moral, write programs that run natively. A 16-bit DOS program running
in an emulated DOS box will never run as fast as a native windoze
program... Ask for a native windoze version on
 or
 and the program will probably run
faster than you can blink an eye.

Robert

PS: Decode the email address, you can send me copies of the .EXE's
renamed to .QQQ and in a ZIP file!
   


Actually I think you may both be missing a significant point.

Native DOS only used text mode input output.   Windows used graphical
output, which consumes a very significant amount of resources by itself,
besides forcing additional multitasking overhead.   I would expect any
operating system that did that using the same CPU and memory to generate
and control graphic output would exhibit significantly less power
delivered to applications.

There is a reason why 1960's mainframes  like a  360/65 with only a 0.5
MIP processor could run a major business -- they only had to deal with
record I/O and text data.  The closest they came to graphics was 3270
full screen displays, and the translation from text streams to display
was handled wholly by external controllers, without adding overhead to
the main processor and memory.  I remember there being management
resistance to even moving from monochrome monocase 3270's to multi-color
dual-case 3270's because of the "unnecessary" extra overhead of
supporting those features.
   Joel C. Ewing


 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday OTT : DOS vs Windows performance

[Joel C. Ewing]

On 10/01/2016 06:24 AM, Robert Prins wrote:
> On 2016-10-01 01:59, CM Poncelet wrote:
>> 't is Friday, so here we go again.
>>
>> I wrote the following in Intel assembler in the 1990's to check the
>> CPU-cycles
>> performance of DOS vs Windows 3.1 (if memory serves), using a 486/33Mhz
>> processor and practically all executable code loaded in the
>> instruction cache:
>
> 
>
>> This took approx 1'45" (elapsed) to execute under native DOS with a
>> 80486/33Mhz
>> processor - i.e. there was a 1-to-1 correlation between the number of
>> machine
>> instructions vs the number of actual 33Mhz CPU cycles.
>>
>> I reran this under Windows XP from the 'command prompt' with a 3.2Ghz
>> processor
>> (approx 100 times faster than a 33Mhz one), and it then took 3'48" to
>> complete -
>> thus about 200 times longer (CPU-wise/elapsed) than when running
>> under native DOS.
>>
>> Moral: Use native DOS (preferably with a DOS extender) for fast PC
>> performance.
>
> NO, NO, NO!!!
>
> Moral, write programs that run natively. A 16-bit DOS program running
> in an emulated DOS box will never run as fast as a native windoze
> program... Ask for a native windoze version on
>  or
>  and the program will probably run
> faster than you can blink an eye.
>
> Robert
>
> PS: Decode the email address, you can send me copies of the .EXE's
> renamed to .QQQ and in a ZIP file!
Actually I think you may both be missing a significant point.

Native DOS only used text mode input output.   Windows used graphical
output, which consumes a very significant amount of resources by itself,
besides forcing additional multitasking overhead.   I would expect any
operating system that did that using the same CPU and memory to generate
and control graphic output would exhibit significantly less power
delivered to applications.

There is a reason why 1960's mainframes  like a  360/65 with only a 0.5
MIP processor could run a major business -- they only had to deal with
record I/O and text data.  The closest they came to graphics was 3270
full screen displays, and the translation from text streams to display
was handled wholly by external controllers, without adding overhead to
the main processor and memory.  I remember there being management
resistance to even moving from monochrome monocase 3270's to multi-color
dual-case 3270's because of the "unnecessary" extra overhead of
supporting those features.
Joel C. Ewing


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday OTT : DOS vs Windows performance

[CM Poncelet]

Yes, the programs were written and meant to run natively - i.e. under 
native DOS - and not in an emulated windoze DOS box.


I was pointing out the horrendous overhead of running DOS programs under 
an emulated windoze DOS box, instead of under their original native DOS.


Some DOS programs (e.g. CTC's SPF/PC) have no native windoze versions.

BTW I have sent a zipped copy of everything to you.

Cheers, Chris Poncelet



Robert Prins wrote:


On 2016-10-01 01:59, CM Poncelet wrote:


't is Friday, so here we go again.

I wrote the following in Intel assembler in the 1990's to check the 
CPU-cycles

performance of DOS vs Windows 3.1 (if memory serves), using a 486/33Mhz
processor and practically all executable code loaded in the 
instruction cache:





This took approx 1'45" (elapsed) to execute under native DOS with a 
80486/33Mhz
processor - i.e. there was a 1-to-1 correlation between the number of 
machine

instructions vs the number of actual 33Mhz CPU cycles.

I reran this under Windows XP from the 'command prompt' with a 3.2Ghz 
processor
(approx 100 times faster than a 33Mhz one), and it then took 3'48" to 
complete -
thus about 200 times longer (CPU-wise/elapsed) than when running 
under native DOS.


Moral: Use native DOS (preferably with a DOS extender) for fast PC 
performance.



NO, NO, NO!!!

Moral, write programs that run natively. A 16-bit DOS program running 
in an emulated DOS box will never run as fast as a native windoze 
program... Ask for a native windoze version on 
 or 
 and the program will probably run 
faster than you can blink an eye.


Robert

PS: Decode the email address, you can send me copies of the .EXE's 
renamed to .QQQ and in a ZIP file!


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday OTT : DOS vs Windows performance

[Robert Prins]

On 2016-10-01 01:59, CM Poncelet wrote:

't is Friday, so here we go again.

I wrote the following in Intel assembler in the 1990's to check the CPU-cycles
performance of DOS vs Windows 3.1 (if memory serves), using a 486/33Mhz
processor and practically all executable code loaded in the instruction cache:





This took approx 1'45" (elapsed) to execute under native DOS with a 80486/33Mhz
processor - i.e. there was a 1-to-1 correlation between the number of machine
instructions vs the number of actual 33Mhz CPU cycles.

I reran this under Windows XP from the 'command prompt' with a 3.2Ghz processor
(approx 100 times faster than a 33Mhz one), and it then took 3'48" to complete -
thus about 200 times longer (CPU-wise/elapsed) than when running under native 
DOS.

Moral: Use native DOS (preferably with a DOS extender) for fast PC performance.


NO, NO, NO!!!

Moral, write programs that run natively. A 16-bit DOS program running in an 
emulated DOS box will never run as fast as a native windoze program... Ask for a 
native windoze version on  or 
 and the program will probably run faster 
than you can blink an eye.


Robert

PS: Decode the email address, you can send me copies of the .EXE's renamed to 
.QQQ and in a ZIP file!

--
Robert AH Prins
robert(a)prino(d)org

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN