Re: which way is faster?

På Fri, 11 Jan 2008 02:11:40 +0100, skrev Frank Kotler <fbkotler@xxxxxxxxxxx>:

//\\o//\\annabee wrote:

...
Write an app, in dos that floats a 256*256 bitmap across a 32 bit formated, vesa canvas. Then I write one using only GDI. Then we can compare the framerate. It would also be interessting to see for other reasons. I never heard of speed comparisons between dos and windows. (Even I guess they exist).

What are you calling "dos"? A "dos box", it seems to me, can't *possibly* be any faster than Windows, since Windows is providing "fake dos". If we start from "real dos", so we can go into "flat real mode", and use a Linear Frame Buffer instead of "bank-switched" hi-res mode, we can go pretty fast. But Windows has access to "hardware acceleration". No theoretical reason you couldn't do it from dos (AFAIK), but you'd need a routine to detect what card you had, and routines to implement hardware acceleration for as many cards as you'd like to support. This is where Windows has got the jump on us - mfg's provide drivers for Windows, and don't tell *us* squat... If we *did* do it, dos ought to be faster, since it's single-user, single-tasking, unpaged... Timer interrupt every 18th of a second or so, and we can turn that off... I don't think I've ever seen hardware acceleration from dos, though - no idea what it would look like.

Well, I didnt mean "dos", I meant bare metal, eg non windows. (any that is choosen)
As far as I know, GDI does not support hardware. (It does not start DirectX in the
background and use that for the GDI builts. (DirectX takes ~half a second to start the first time).(and GDI builts are too slow that I think it does it by some spesific shortcut to the hardware acceleration - even I am not 100% sure)

When I checked the line APIS against a DIBsection (backbuffer=memory) they was optimized pretty damn well since the books I read about the subject. I was unable to write faster code, until I started playing with the prefetch directive. And the GDI built is roughly as fast as that. But not as fast as hardware. (Maybe Herbert knows better on this).

When it comes to multitasking, I just have to repeat that this is not a problem. Both Windows and Linux uses premptive multitasking which means that you can PRE empt other
processes. It is pictured as rings of priority, where the tasks are linked to each other in each ring, and where no lower ring gets a chance to run, if theres is still work to be done in a higher ring. You can preemt the system, and steal near all cycles to yourself. I provided a demonstration here earlier, where a GDI app, can prempt both the mouse and keyboard messages, and keep going. Not very useful, but possible.

The reason I guess why some ppl dont think that it works that way, is that windows is a eventdriven os. That means that until your app gets some kind of message, it is simply a dead piece of memory, doing nothing. But, having a timeslice, and been given a message,
(its not enough to just have a timeslice) - you can set your app at a realtime priority, and call peekmessage instead of getmessage. Peekmessage is not blocking, and so you can continue running the app, after it returns, and with the full priority, you will receive all the timeslices for the ring. And with that you can totally preempt the system, leaving your app, the only survivor. Even the system reads and takes cares of priority interrupts, it will not be able to send you any messages. But you will have the slices, and you app will "work". Basically at this point you can start DirectInput, and read the keyboardbuffer directly, to see if there are keys beeing pressed...(not tested) etc.

(This is some guesswork, and some observation and some of the material from the SDK).


If hardware acceleration were "outlawed" in the Windows version, I think dos could be made to go faster, just from the lack of "competetion".

Thats what I like to find out.
It could be interessting to see the diffrence, if any.


Best,
Frank



.

Relevant Pages

  • Re: DOS applications ?
    ... A DOS batch file runs dos programs sequentially and can run ... command prompt window and keep the second command ... Windows APIs to do it. ... A 16-bit DOS app running on pure MS-DOS cannot launch another app ...
    (microsoft.public.vc.mfc)
  • Re: how to call print screen and how to read windows clip board
    ... between our DOS versions of our software's screen contents and their ... own WORD or other Windows softwares's screen contents. ... just want to export the ASCII text from your DOS app to ... If your clients normally run your app full-screen, ...
    (comp.lang.asm.x86)
  • Re: Great SWT Program
    ... can have its own cursor/selection independently of the underlying ... it and the underlying app will contend for the one and only text-mode ... A DOS box is a full blown VM ... You normally can iconify in this circumstance in Windows too, ...
    (comp.lang.java.programmer)
  • Re: Confusing stack effects
    ... And DOS ... is the best way to start assembly programming. ... To learn todo 16-bit dos programming, for programming in windows later is the worst kind of advice. ... Learning to program for a Click&Go GUI is a tedious incredible complex job, compared to doing a dos app, where all you need to do is set up a loop, to take input that in all cases _you_ made the rules for. ...
    (alt.lang.asm)
  • Re: One thing I noticed
    ... I remember sitting down with my boss once and he asked me what ... > for the existing app. ... Your reference to a port from DOS to Windows does not fit your argument. ...
    (microsoft.public.vb.general.discussion)