Does XP still use the win16mutex?

In previous versions of windows calling Lock on the primary surface in directdraw would grab the win16mutex and prevent other apps from using DirectDraw/GDI to update any portion of the screen until it had been unlocked. I am trying to do the same thing under XP, and it will not work. Either my code is buggy, or XP just won't let you do it anymore. Which is it, API XPerts?

Also, is there any other way to prevent any application from accessing the display while my application has it locked? I've have googled my brains out. Either I don't know the correct search terms, or it can't be done without writing a driver. Please help.
Posted on 2003-08-25 07:33:33 by emonk
Theoretically win2k and winXP will NOT take the win16mutex anymore when using directdraw ::Lock() on primary surface, this is why some artifacts might occasionaly apear on screen on win2k --like when wm_paint or erasebkgrnd messages appear at random

Also take care as DX8 and DX9 do not alow you to ::Lock the primary surface anymore anyway :P, the last one that allows you that is DX7 AFAIK
Posted on 2003-08-25 17:10:21 by BogdanOntanu
Also take care as DX8 and DX9 do not alow you to ::Lock the primary surface anymore anyway :P, the last one that allows you that is DX7


Thank you for your helpful answer. Please, bear with me as I am fairly new to directx, but as far as I understand it looks like I could just request a directx 7 interface, and it would work the same as if I had directx7 right? Or was the feature removed entirely to prevent 'rogue' aplications crashing and taking the entire display with them? Do you know where I can find more information? I have the MSDN, and I cannot find anything in it or google that seems to be relevant. Perhaps my search terms are useless? Any ideas what I should search for? Is the win16mutex still used by windows? If so is there a way for me to get it? If not what would be YOUR next step if you wanted to prevent another app from updating anything on the primary display surface? A driver perhaps? Maybe some sort of weird voodoo with subclassing the desktop and tossing out or delaying the messages? Subclassing all running windows? I am stumped, and need to find a way to do this. I am writing a subliminal messages application, and need to be able to lock the display for a specified number of frames (usually one - three frames) to prevent other apps obscuring or obliterating the subliminal messages, or my app messing up the other apps window. My app should work like this:


1)Copy rect of screen to 2 backbuffers
2)write message text to backbuffer1
3)write rect with text out to screen from backbuffer2
-----Trouble is at step 4 ------------
4)lock entire display (or just rect whatever works)
5)wait specified number of frames
6)write unaltered rect back to screen
7)Unlock primary display


Any advice, or answers to ANY of my way too many questions would be much appreciated.
Posted on 2003-08-26 09:03:09 by emonk
Yes you can ask for DX7 interfaces and get it even IF the PC is running Win2k / XP and using DX8,9

I do NOT think "subliminal messages" ever fit this forums set of RULES

Take care... You are on the edge here....
Posted on 2003-08-26 13:12:55 by BogdanOntanu
Subliminal messages are not 'naughty' necessarily. I want to create an app to experiment with. Mostly quiting smoking, or losing weight types of things. Its just a toy.
Posted on 2003-08-26 13:18:59 by emonk

Subliminal messages are not 'naughty' necessarily. I want to create an app to experiment with. Mostly quiting smoking, or losing weight types of things. Its just a toy.


1. make fullscreen DX window with desctop resolution and one back buffer
2. copy all screen to backbuffer
3. write message text to backbuffer
4. flip
5. wait
6. flip
7. destroy DX
8. I'm hope I'm not on the edge here:stupid:

P.S. One time one man from my work was very busy playng Solitaire all the days, so I wrote some silly prog to help him with this (don't relly on its name ;) )
Posted on 2003-08-27 03:58:15 by S.T.A.S.
S.T.A.S.,
As far as I know you cannot flip to the primary surface. Unless it is a new surface, and if I create a new surface wont swapping over to it cause a noticeable (more than one frame) delay before the 'desktop' is redisplayed? Also, I am not sure how the code you gave me is relevant to my problem? Its kind of a finny joke, but not very useful to my purpose? If a create a new surface and swap to it then I can do my blit and swap back, but that seems like an awful lot of overhead that I don't need.

Does anyone know how to use the NtGdiLock call? according to MSDN its declared in ntgdi.h and I have to dynamically link to D3D8THK.DLL. I tried that but get 100+ errors starting with 'error C2065: 'ARCTYPE' : undeclared identifier' (this is in visual c++ 6.0 using the latest SDK). I think that by bypassing directx and calling NtGdiLock directly I may be able to lock the primary surface. Any ideas?
Posted on 2003-08-27 10:22:20 by emonk
I am under the impresion that emonk wants to do it no matter what and while other DX full screen applications are running, i am also under the impression that he wants to use DX8 (since he references D3D8THK.DLL). DX7 surely allows you to flip to the primary surface once in exclusive mode.

I also guess that if he wants it for educational purposes and/or for his own usage (like in he wants to quit smoking) he could use DX7 and avoid launching other full screen DX applications meanwhile.

Anyway you are not on the edge S.T.A.S. , emonk was but i have alowed this line of questioning to continue since he PMed me and explained...

i am still not very convinced by his arguments but doh... i thnik he deserves a little benefit of the doubt here
Posted on 2003-08-27 11:26:53 by BogdanOntanu
I also guess that if he wants it for educational purposes and/or for his own usage (like in he wants to quit smoking) he could use DX7 and avoid launching other full screen DX applications meanwhile.


I could do that but then how would it work while I'm playing quake :)

Update: Ok. I finally figured out how to bypass directx and use the NtGdiLock call, but I had to use D3D8THK.DLL as a wrapper. So basically I was dynamically loading d3d8thk.dll and calling OsThunkDdLock Which in turn caused the kernel to pass my request straight to NtGdiLock in the kernel. I think :) Well anyhow it still returns ok (actually DDHAL_DRIVER_HANDLED ) , but no joy :( So now I think maybe I'll try going through GDI32.DLL and calling EngLockSurface, but I dont think that you are supposed to call EngLockSurface from user mode. Oh well. I guess I'll try it and see.
Posted on 2003-08-27 12:26:43 by emonk