gta2patch.exe (7 kb)

Please bear in mind that this patch is VERY ghetto. It doesn't even check if you are patching the right version, so USE AT YOU OWN RISK!
For the details, the source code and the alternate methods (if you don't feel like downloading and launching an executable from an unknown source), hit the jump.

I won't go into big details but it seems at some point the code to detect whether or not your graphic card is capable of handling high resolution screws up decides that it can't and falls back into "safe mode" by setting a flag. For another weird reason, the flag is not set when a registry key is.
Try to set the DWORD key skip_frontend to 1 under HKEY_LOCAL_MACHINE\SOFTWARE\DMA Design Ltd\GTA2\Debug and it should launch the game at high resolution. The problem is, the game fails telling you that it can't open some file. Whatever.
So what did I do, well, I simply patched the fail-safe code, by forcing high-res.

If you want to patch it yourself, take you favorite hex editor and open gta2.exe. Go at offset 0x000CB2C9, and replace 74 1D by EB 1D (forced jmp ftw).

Finally, if you want to compile the patch yourself (some people do I guess!), here is the code! I told you it was ghetto!

Jump for the (quite long I admit) story

Last year (Oct. 2006) I started playing with the Windows Vista's Destkop Window Manager (DWM) API. Like a lot of people, I was really disappointed by the library. The only thing it permits you to do is to have your own live thumbnails... Come on Microsoft! The DWM uses freaking Direct3D, why don't you let us mess around with that!
I knew there a way to extract the window texture (since DWM uses Direct3D9Ex and its marvelous shared resources), so I started a thread on AeroXP.org to expose my progress on this.

I started of by disassembling dwmapi.dll, and it paid off. Here it was, in front of me: DwmpDxGetWindowSharedSurface()! ...and its 32 bytes signature! Damn, that's 8 parameters maximum to reverse! Arg.
But after spending almost 2 months reverse engineering, it eventually paid off. I had a (almost) complete function signature, and even a way to use it.

int __stdcall DwmpDxGetWindowSharedSurface(HWND hWnd,
                                           LUID adapterLuid,
                                           LUID someLuid,
                                           DWORD *pD3DFormat,
                                           HANDLE *pSharedHandle,
                                           unsigned __int64 *arg7);

But there is a "but", the function would return me a correct texture handle but to a black texture! After weeks of trying to tweak the code, I was facing a dead end.
So, taking my courage, I mailed the WPF Architect, Greg Schechter to ask him for help, without much hope about a response. But he did reply (and that was very kind of him to do so), thanking me for my interest into the DWM, but that he couldn't comment on such things (and it's understandable).

And here I was, lonely, facing a dead end. Eventually the project was forgotten on my hard drive (as many others).

But after some months, Jeremiah Morrill followed by work, and scratched some more dust, finding that the texture wasn't black when the window used a Direct3D device, like WPF. And after all, it makes perfect sense. Direct3D applications render to a shared texture given by the DWM, as stated in Greg Schechter's blog:

DirectX window redirection is handled by having the DirectX system, when it's determining what surface to provide the app with to render to, make calls to the DWM in order to share a surface between the DirectX client application process, and the DWM process. This "shared surface" support is unique to DirectX atop the WDDM, and is another key reason why WDDM is an absolute requirement for running the DWM.

But there we were facing the same problem: how the f*ck do we extract the window texture, for all windows?

A few months later, I started talking to Andreas Verhoeven about this (he was doing some reverse on other parts of DWM on his own), and eventually, I revived the project. After a few nights of work, there it was:

The texture relies on hooking IDirect3D9::CreateTexture() to watch out for newly created textures by the DWM, and mark them as shared (GDI texture are not

However, the technique is flawed. The main problem is that the render loop is done asynchronously of windows creation (synchronous with v-sync), there was no direct way to establish a HWND <-> TextureHandle relationship. More importantly, the rendering is done though MIL (milcore.dll), and MIL doesn't have any clue of windows objects, that are handled by uDWM.dll. Pseudo dead end again.

But I didn't stop here, and thank to Andreas, I dug deeper into the DWM. And the results, you saw them at the top of the post
I won't expose exactly what's involved (yet), but it's a combination of internal calls, and API hooking

And for those of you who wonder, yes, I'm working on a library to do all this!

After a while, I wanted to grab some videos and put them on my phone, so I started to search for an application that would allow me to convert flvs to mp4s, and eventually I found some. But the process is kinda slow, and when you think the iPhone plays the videos directly in mp4 from DailyMotion (and YouTube), you would find this utterly inefficient!

But thankfully for you guys, there is a way to download videos directly in mp4 from DailyMotion, and by directly, I don't mean using some transcoding service. I mean directly.
So how do we do that? Well, I've created a simple tool for you to convert DailyMotion urls, to direct download MP4 urls

Thanks to this simple utility, just put the original URL, click "Find!", and it will give you the direct download URL to the MP4 file! It's that simple.

You can download the tool here, and download the sources (VS 2008) here.

Let's analyze this.

First, we notice that the function moves the first argument in esi and then references some data (like in a structure) from esi.

However, HWNDs are not pointer, which tends to demonstrate that the first argument is NOT an HWND, but likely the internal structure kept by the kernel for each window.
If we go back to the call to xxxPrintWindow() in NtUserPrintWindow(), we notice this:

The last 2 arguments are forwarded from the original PrintWindow() call, and the first isn't, instead it is eax. So, when does eax get set? Well:

So here we are, ValidateHwnd() (which is __fastcall), must converts a window handle (HWND) to a window structure pointer. For clarity, let's name this type PWND.
We can then extract the following prototypes:

PWND __fastcall ValidateHwnd(HWND hwnd);
BOOL __stdcall xxxPrintWindow(PWND pwnd, HDC hdcBlt, UINT nFlags);

And then we look at the rough function flow:

Oh, there is one interesting thing: according to this function, we notice that the Win32 GUI does implement the concept of window drawing redirection; this basically means that the GUI is able to redirect all the drawing call into a off screen bitmap, instead of the real window, on the screen. This is actually "documented" on MSDN:
"The second way to use layered windows is to continue using the Win32 painting paradigm, but allowing the system to redirect all the drawing for the layered window and its children into an off-screen bitmap."

In what way is this interesting for PrintWindow() ? Well, thanks to this, the API can screenshot partially or completely hidden windows. This is, to be fair, the core advantage of this API.
So, according to all this, how does it work? Well, it does the following:

• Sets the window to layered using SetRedirectedWindow()
• Redraws completely the window using UpdateWindow() in the newly created empty off screen bitmap
• Gets the DC of the new of the window with GetDCEx()
• Copies the bitmap to the provided DC using NtGdiBitBlt()
• Releases the new DC
• Unsets the layered attribute

So we now know why PrintWindow() permits to take screenshots of partially or completely hidden windows! This is because of the existence of layered windows!
So, even though the API appeared in Windows XP, the very existence of layered windows goes back to Windows 2000. Which means reimplementing it on Windows 2000 is totally possible, using a kernel mode driver which would call the kernel mode functions.

But what is interesting here is the concept of off screen bitmaps. So basically, there is a pointer with DIB data of the windows! This could be very well suited to make a replica and even optimize the PrintWindow() implementation! Why would it be a good thing? Well, here is what we need to do to take a screenshot to a texture:

• Get the first surface of the texture
• Get a DC to this surface
• PrintWindow() into this DC
• Release the DC
• Release the surface

While this could be not quite cumbersome to some of you, there is one problem: what if the window has a mask? Like MSN windows? Well, here are the steps involved:

• Create a temporary DC
• PrintWindow() into this DC
• Get the first surface of the texture
• Get a DC to this surface
• BitBlt from the temporary DC to the surface DC, using the mask
• Release the 2 DCs
• Release the surface

All of this copying, allocations, and GDI stuff is quite slow. What if we had a direct access to the window DIB? We would only have to copy the DIB data to the locked texture. But even more powerful, using a standard 2D API like SDL where image DIB are stored into the system memory, we could even point the pointer to the DIB maintained by the OS, not having to worry about the updating, without even polling!

And here is the new quest, finding this damn pointer, so we can make something like this:
Pretty fun eh?

So here I am bombing you with assembly... How rude...
In order to know what happens, we could try our analysis by looking at the calls the function does:

And what do we see:
- EnterCrit/LeaveCrit: this functions are used for thread synchronization. It must be here to prevent the function from being executed more than once at the same time. See EnterCriticalSection and LeaveCriticalSection.
- ValidateHwnd: we don't know at the moment what it does, but we know it's __fastcall (thanks to the mangling), so it must be called very very often.
- xxxPrintWindow: interesting, must be the underlying PrintWindow implementation.
- ThreadUnlock: used to unlock the thread
- UserSetLastError: used to set the last error in case something went wrong.

With all this it's pretty fair to assume the real PrintWindow code is actually done in xxxPrintWindow.

And here is what I came accross: