• Advertisement
Sign in to follow this  

Is it possible to get rid of win procedure?

This topic is 3626 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

It is trivialy easy to get rid of WinMain and start windows app from "standard" main instead. But is there any way to get rid of windows procedure as well and do your own poll of input devices? In case when we run in fullscreen there are not many window related messages to process but input. I am just interested if there is some way to call nt services directly and go around win proc entirely to do keyb/mouse/joystick polling instead or one is dooemed to go through winproc? Creating windows class with window proc sett to 0 of course crashes app directly after initialisation :-), but if one create empty winproc, windows will obvioulsy generate all messages as usually, it is just that we are not handling them, but overhead is still there. Actually even if we don't register a winproc, windows will probably generate all messages anyway, it just crashes when it tryes to pass them to the app. So I wonder if there is some way to entirely bypass win32 layer, and do windowing through the kernel itself. I know it is not a trivial thing, just wonder if anyone has tryed (and succeeded) with that?

Share this post


Link to post
Share on other sites
Advertisement
Quote:

But is there any way to get rid of windows procedure as well and do your own poll of input devices?

Not really.

Quote:

In case when we run in fullscreen there are not many window related messages to process but input.

False assumption; there are many messages that a well-behaved application should process beyond simply input.

This isn't really feasible to do in userspace, and it's not really any kind of "overhead" at all. If you're running under the OS, you're going to play by the OS's rules. It's going to send you those messages whether you like it or not, and just because you don't have a procedure to handle them, doesn't mean they will not get handled. You'll just spend your time doing the default processing. Even if you took the appropriate drastic steps to go around it, you'd just end up reinventing half of it since you won't get those messages you think are important anymore -- you won't get anything.

You should not be concerned about it whatsoever in terms of overhead. Calling main() consumes 100% of your applications time anyway. Do you want to remove that? Removing the window message pump procedure is only slightly less drastic.

If you don't like dealing with it, just wrap it. But it doesn't cost you anything.

Share this post


Link to post
Share on other sites
I'm not entirely sure how much overhead there is in using the window procedure. Have you profiled and found that this is your bottleneck?

In any case, Microsoft have deprecated DirectInput (unless you are using joysticks), so I'm guessing no.

Share this post


Link to post
Share on other sites
DI hooks the window procedure, though. Sure, you may be able to "look like" you're avoiding the procedure, but it's still there -- it doesn't address the OPs misplaced concerns about the 'overhead' of the procedure, which are basically unavoidable if you're going to be running under the OS.

What you have to give up to get rid of the procedure completely is essentially every OS service you're used to having. It's 100% not worth the effort.

Share this post


Link to post
Share on other sites
Quote:
Original post by rip-off
In any case, Microsoft have deprecated DirectInput (unless you are using joysticks), so I'm guessing no.

Has DirectInput been depreciated? Man, I am gonna have to re-write all of my input classes.

What has it been superceeded by?

Share this post


Link to post
Share on other sites
Quote:
Original post by rip-off
In any case, Microsoft have deprecated DirectInput (unless you are using joysticks), so I'm guessing no.

Has DirectInput been depreciated? Man, I am gonna have to re-write all of my input classes.

What has it been superceeded by?

Share this post


Link to post
Share on other sites
Quote:
Original post by lonewolff
Has DirectInput been depreciated? Man, I am gonna have to re-write all of my input classes.

What has it been superceeded by?


XInput, which works for Windows and XBox360

Share this post


Link to post
Share on other sites
Quote:
Original post by Rattenhirn
Quote:
Original post by lonewolff
Has DirectInput been depreciated? Man, I am gonna have to re-write all of my input classes.

What has it been superceeded by?


XInput, which works for Windows and XBox360


Plain WinAPI messages (WM_KEYDOWN, WM_MOUSEMOVE et al) were also recommended for some time (DirectInput being a wrapping layer over those), although it might not be the case anymore now that XInput exists.

Share this post


Link to post
Share on other sites
@jpetrie

Apologies, having never actually used DirectInput, I assumed it was more "Direct", just like some of the other members of the DirectX family. However, now that you have mentioned it I vaguely recall something about DirectInput just using windows messages in a separate thread, or something similar.

@lonewolff

A common mistake, one I made myself when I first was introduced to the terms:
Deprecation vs. Depreciation [smile]

Share this post


Link to post
Share on other sites
yeah ... direct input is said to be a wrapper to raw_input these days, so you can call raw_input directly, it has been over and over topic on this forums, so do search ant don't hijack my thread :-)

@jpetrie, if you run in fullscreen you don't care about resize, move etc ... yeah, as I mentioned above, just because you don't have a win proc mess, it doesn't mean system don't generate messages; that's why it crashes if you put winproc to 0 when registering the class.

My thaught is that win32 is an API, a layer over NT services and core system. I am a guy who like ot digg deep under the hood, so I am just wondering how it would be to get a window without win32. That is maybe impossible to achieve in windows case. Maybe they have digged win32 api so deep down to the system core, so you can't go around it. I am just interested if anyone managed to break the concrete wall of that ugly API.

Otherwise, I have wrapped and abstracted away win32 and window creation, input etc, and it is not some bottleneck, rather an interseting and curious thing :).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement