DxWnd changelog - all release news here.

[gho]

v2.01.100:

Ho ho ho: it's Christmas time!
And I'm getting out with this important release number: 100!
Too bad there's nothing spectacular in it, or perhaps not?
Actually, you may say that this release is dedicated to two games:
The first one is "The Grinch": it is one of the few obscure games developed in OpenGL (would you guess it?) and introduced in the DxWnd logic a few tricky things that I had to take in account: see the release notes, if you're interested.
Right now, windowing is far form perfect (e.g. the text positioning in scaled windows is not right!), but it's a good start. But window handling, opengl wrapping and other tricky things are a prerequisite to properly manage some other more interesting piece of fun like Half Life and its long sequel.
The second game maybe is important for me alone, but "7th Legion" is one of the very first games that I attempted to manage, and it's unbelievable how odd it is internally coded and how long it resisted to be properly handled.
As far as I know, it is the only game that uses the WM_NCHITTEST window message to tell the cursor position, and that forced me to add an extra option in the mouse options that maybe will stay forever for this game only.... but finally the game is playable, even in a scaled and moved window, as it was supposed to be!
So, let me cut this short and run to the Christmas dinner with my family.
Happy Christmas to everybody.
GHO

[gho]

v2.02.00

Hi.
I'm placing in the dowload area the new v2.02.00 release: no new features (maybe some new bug!) but a partial and unfinished code rewriting to clean up things a little.
Right now most of the ugly global variables have disappeared and the windower logic has begun to move to a neat dxwCore class object.

[gho]

DxWnd 2.02.01 is out.

The major thing about this v2.02 stuff is the beginning of a code rewriting to introduce an object class to handle in a common and neat way all the windowing logic. So, in practice, dxwnd hooks are and must remain plain C procedures (because they must mimick their real counterparts), but they will refer on the dxwCore class methods to make common calculations about window resizing, mouse displacement and so on.
All this will produce no effect whatsoever in the external DxWnd behavior, but should make it easier to understand and modify its inner logic, so hopefully should make it a better piece of code.

But, talking about features, the 2.02.01 release has a couple of interesting and unfinished ones:

first of all, I saw that several of you (and me too!) are interested in making the old glories of the past playable again, and this may require some speed tuning. A new configuration section was added to handle the FPS (frame per second) features, to slow down the program (FPS Limit), make it faster (FPS Skip) and report the current FPS value on the status panel.
So far all this applies to GDI and DirectX 1-7 programs only, leaving out D3D and OpenGL stuff so far. Let's see...
Also, the limitation logic is not 100% satisfactory: right now the program is paused (by a system Sleep) while it would be perhaps advisable to process the message queue in the meanwhile. I tried it, but I got nasty side-effects on some program, so the right methods to proceed is still under investigation.

The second feature is the "Hide multi monitor config." that makes the program believe you have a single-monitor PC even if that's not right (I have two!). This currently intercepts D3D8 and D3D9 programs only, but (thanks to our friend Garry) I applied DxWnd to the
Dream Aquarium screensaver (anyone can get a free demo at http://www.dreamaquarium.com ) getting wonderful results, once I turned off my second monitor in DxWnd through this flag. Could it be useful on some other multiscreen-aware game? Please, let me know...

enjoy
GHO

[gho]

v2.02.02

Very little news on this release, but some of you may enjoy it anyway.
A preliminary time stretch option let you increase or decrease the program clock, causing any prograsm that is timed upon the GetTickCount API to slow down or speed up from 16x slower to 16x quicker.
The option is currently controlled by Alt-F5/F6 keys (no key remapping so far, I'm sorry!) and of course doesn't work with all programs.
But I tested it with Diablo and Warcraft II - aren't they worth a try?
So, now you can walk into the dungeon, spot an enemy and plan carefully a slow-motion attack, and finally, if you get just too hurt, literally "run" to town to refill your health potions.
Also the release fixes a blitting problem by GDI functions.... that fixes the Total Soccer 2000 splash screens. Too bad that the time stretch option is not working tor this fast & furious game!
Comments and suggestions will be welcome. Also, some help from people able to reorganize a GUI designed in MFC & VS2008.
bye
GHO

[gho]

v2.02.04

The biggest news about this release is that DxWnd is far from becoming consolidate!
I started in this direction by reorganizing code and stuff to get a cleaner and stable coding, but in the meanwhile a few things happened:

1) I tried d3dwindower and, looking at some internals and its behaviour, I saw that it handles a few important details differently and better that DxWnd! Then, there's work to do to discover the d3dwindower inner logic and emulate it.
2) I added this new Time Stretch feature, that is just too funny and useful. Try playing Diablo at the speed you like, and you'll see how I'm right! But it's just preliminary, and there's a lot of games that don't stretch at all or just for a while.
3) I fixed a major bug in the syscall hooking, and now I saw that DxWnd can reach parts of code where it didn't get before. A chance to fix several games.
4) and, at last, you wrote about many beautiful games that still have problems and wait for DxWnd improvements.

So, I seek for help: I'd need these skills:
- a MFC expert that would help to introduce tabs into the configuration dialog and put some order in the incredible mess we have in that panel
- an expert of the SetWindowsHookEx call to hook not at the WH_CALLWNDPROC event but using messages events that intercepts the program at an earlier stage like d3dwindower does
- an expert of directx call that could explain how to obtain a valid DC using DDSurface::GetDC when the screen is set to a different color depth: my solution is computionally very heavy and d3dwindower seems to do the same things quite more efficiently!

In the meanwhile, enjoy this fine DxWnd release.

[gho]

v2.02.05
Few changes, but a necessary one to make the Age of Empires series work with the time shifting capability. Your cavemans are too lazy? I assure you after my cure they'd run as obsessed!
Enjoy!

[gho]

v2.02.06
Massive speed improvement for all games formerly requiring the "Handle DC" flag set:
- Age of Empires
- Age of Empires II
- Hyperblade
and so on.
Turn the flag off and test it.
P.s. Hyperblade does now need some slowdown with the frame limit parameter (delay about 50 msec)

[gho]

Many fixes in this v2.02.07 release, mainly on FPS and speed control.
Speed control tested successfully on Doom95, Return to Castle Wolfenstein, Watcraft 2, Diablo, Age of Empires I & II.....
Other games still have weird behaviours: Tomb Raider 2 (no speed change), Starcraft (speed reset).
But bullet time on old games is fun!

[gho]

v2.02.08:
fixed some errors in the main directdraw palette descriptor. That gives better compatibility and less complicated source code. added Fake Version feature: now Dungeon Keeper II (original version, not GOG hack) can detect a fake Win2000 / WinXP environment on Win7 and newer. Tested and working on Win7. Many thanks to Maxim for pushing me hard to win my lazyness and implement this new feature.

Now that I've changed my OS from XP to Win7 I'm starting to test DxWnd properly on this new platform.
One of the most annoying problems is the "Default IME" window that stops reponding, usually during fast intro movies (DK2 is an exaple!).
I've tried several ways to overcome the problem (that may depend on some specific driver, so I don't know how many have experienced the same problem) and at last I've found that maybe the best way to manage it is to set the "Optimize CPU" flag, or maybe setting some small FPS limit delay.

[gho]

v2.02.09/10: ok, new releases, just read the readme.....

A few more words to explain what's going on. I had some troubles to make an old glory working, that is "Postal". This game uses the window coordinates in a peculiar way (though a correct way!) that required a fix in the ScreenToClient & ClientToScreen system calls hooks. Furthermore it uses the mouse in a peculiar way, so I'm just too happy that in the end everything (well.... almost) fell in place.
In the release archive I put the dxwnd.sample.ini config file that is not used by default, but can be opened to see and copy proper game settings. So, if you want blood and gore, grab the old Postal and shoot.
I hoped that this fix was helpful to improve another pain in the neck, the "Urban Assault" intro movies, but that's not the case. So, I resumed an old quick and dirty trick, the "Full RECT Blit" option that forces blitting to the primary serface using the whole area instead of the rectangle identified by the Blt call. In this way the game ignores any wrong computation about x,y coordinates, and if you're lucky the game is playable.
Too bad that Urban Assault crashes after the intro movies, but this is something I plan to fix somehow and sometime.
Release 9, then, have a fix in the FPS limit handling that makes the whole thing more reliable. Keep in mind that for DxWnd a frame is a blit operation to the primary surface, but some old games update the screen seveal times (in different areas) at each frame change, so the game speed could be unexpectedly slow. In this case, you can only adjust the delay parameter by attempts and find the better value for your needs.

[gho]

v2.02.11:

Fixed the Urban Assault intro movie problem (ehi, that wasn't easy at all!!), now the Full RECT Blit option is not necessary.
Added the "Palette update don't BLit" flag to eliminate some nasty flickering when GDI and directX operations conflict. I know there must be a better way to handle this, but just consider it as a useful workaround. Don't set it unless you notice some flickering on screen.

[gho]

v2.02.11:

Finally, after so many aborted attempts, I managed to release a new GUI with tabbed configuration panel. This means that there will be plenty of space to orderly insert any configuration option without getting lost in the interface.
So now DxWnd can evolve from a (relatively) simple widower to a more fully functional program/gaming control center! Any ideas? I'm sure there will be plenty of things to do.
Oh, and I almost forgot the other new functionality that can't be missed in any professional program! Now DxWnd has a slpash screen shown at the beginning. If you don't find it cute and lovely, don't worry: there's a "No banner" option to get rid of it.
Last but not least: in the config panel you may notice the "Run in Window" option: this one is currently disabled, but in the near future my plans are to make some functionalities like compatibility patching, exception handling or time stretching available also to who may want to run a game in the original fullscreen mode as well.
So, this release brings no practical changes in the engine, but it's a first and important step to DxWnd evolution. Enjoy!

[gho]

v2.02.14

The new release makes "Wargames" and "Nocturne" both playable smoothly and in emulated mode.
The delay in the last release was caused mostly by a very busy time, but also by the attempt to add a code injection technique to add some hooking logic before the first window is created (that is the event triggered by the SetWindowsHook API): so far I've just completed the part of injecting "something" in the code, so now I have to build all the necessary logic, but it's a more trivial task. Let's hope to get good results!
This is the reason why in this release you may notice a disabled "Inject DLL" option in the main configuration panel. It will be enabled when made fully working.

Update: the v2_02_14f1_build.rar file fixes a small but nasty mouse handling problem. See the Wargames thread.

[gho]

v2.02.15

Thanks to Vovchik, we noticed and started to handle the problem of aero mode compatibility for windowized games. Vovchik discovered some criteria (setting a clipper area to delimitate the primary surface) and the ddraw undocumented API SetAppCompatData to let the game run without killing the desktop aero mode. So, the main feature in this release is the "Set AERO compatible mode" flag in the DirectX tab.
Also, the release includes the v2_02_14f1 fix.
If anyone is willing to cooperate, we need this help:
1) regression problems: is the new release causing problems to other games that were working better with previous releases?
2) SetAppCompatData documentation. The API is invoked with guessed parameters, but we ignore the meaning of these.

Updrade: my mistake, the clipper fix simply wasn't there. If you need it, grab the updated v2_02_15f1.rar build. About sources, well, it's enough to #if 0 the part that is currently #if 1 within the extCreateClipper hook function, that's all.

[class101]

Set AERO compatible mode works very good here

It no more switches to Windows 7 Basic theme while running Comando 1 in an emulated surface

Makes sense yeah for the clipper thingy, it's present in the dx sdk samples in windowed mode

SetAppCompatData looks very interesting

[gho]

v2.02.16

Well, let me say loud and clear that this is NOT just another fine release like the previous ones. Forgive me, but it's necessary to get to the point with calm.
So, DxWnd is the improvement of the original DxWnd project that was based on a few clever tecnical assumptions: first: use SetWindowsHook system API to inject code into a given executable, second: redirect PE function addresses so that the graphic calls are intercepted and hook routines are triggered.
This solution is not the only possible one: if you see the d3dwindower tool (I did!), you may noticed that some games are emulated better, and some are not. Looking a little outside and inside (thank you again, Olly!) you can see that its logic is different in the first assumption: there no use of SetWindowHook, but the InjectDLL technique is used instead. It's just too bad that d3dwindower never went open-source.
Saving most of the details, what's the difference? Well, it's pretty simple: SetWindowsHook intercept any program no matter of father - son relationship (that's why DxWnd and NOT d3dwindower can run in the background, waiting quietly that you start the program no matter how), but the logic is injected upon a triggered event, a window creation in this case. This means that anything happens BEFORE the first window is created is out of reach of DxWnd and can't be patched.
On the contrary, d3dwindower uses the DLL injection, that injects alien code into the program even from the very beginning, but as cons requires a father - son relationship between the programs. This is why d3dwindower only works when you start the game from its menu, but on the pro side you can patch anything with no limitations.
Well, this is all over, now! I added some Injecting logic in DxWnd as well, so that you can continue to take advantage of windows hooks for most of the games, and set DLL Injection for the tough ones, at the price of the need of activation from the DxWnd menu.
Of course, this is just the beginning, and to start with something nice, I tested DLL Injection on the OpenGL games that have this nasty habit to retrieve OpenGL functionpointers BEFORE the window activation and for this purpose were impossible to manage with previous DxWnd releases. What type of odd games am I talking about? Well, I'm sure you're pretty familiar with a cute little game called Quake 2....
Then, just to release something very special with some extra bonus (and reduce the number of releases) I also included a funny little feature of showing the OpenGL games in wireframe mode. I assure you that Quake 2 is almost umplayable this way, but it's funny and pleasant anyway.
So, enjoy this initial release that opens a huge amount of incredible possibilities.
bye
GHO

[gho]

v2.02.18

Several improvement, but most of all the fixes and configuration to make Homeworld 2 running in a window, even though the resizing still doesn't work correctly (the window resizes itself, but the graphic on screen doesn't!).
And a start for D3D10/D3D11 hooking. So far, the more difficult thing has been finding a playable D3D10 game: most of the old stuff I've got is quite happy with D3D9. Anyone would suggest a good start?

[gho]

v2.02.19

Many many improvements, all related to a proper window handling with the "Remap client rect" option checked. But all is in the release notes can be summarized with this sentence: Diablo came back!
Be aware that proper setting is required to manage all child and control windows created by the game (you can get these settings form the example config file included in the release) and still there are some problems, such as it's not recommended to try to resize the windows before you enter the game screen, and the occasional translation of all menus in japanese.... but these limitations are nothing compared to the pleasure to have Diablo back even on Win7.
And the proper window handling shows its benefits somewhere also: for instance, now Premier Manager 98 has a correct mouse handling.

Pehw! I'm exausted. You enjoy!
GHO

[gho]

v2.02.21

This is a w.i.p. release with many many improvements and some radical change in hooking approach, born to track a couple of problems in D3D9 games such as Need for Speed Underground 1 & 2.
The bad news is that the problems are still there, but on the overall the release seems much better that the previous ones for recent games, so I decided to release it, also to have meaningful feedbacks from you, since you started to complain about problems that could be no longer there, or just be different.
So, this is a release dedicated to whom whish to help in the debugging, and if you're happy with your current release, maybe you'd better leave it here.
Many thanks to MSX8, Anonanon and Ozymandias Llewellyn who provided good food for the brains.

late update: a very stupid bug in the GUI required a "fixed" version to be uploaded to replace the previous one. It's ready in the file section, Sorry.

[gho]

v2.02.22

This release has a lot of changes and new features. I hope you'll understand that there's too much stuff to have everything set with no mistakes. Expect some regression and please signal problems to me.
The main change is a new way to distribute the package: this is the last time I'm including a dxwnd.ini in the package, since now it's possible to export and import configuration items: I'm going to include in each release the configurations of the new supported games that you may (or may not!) import them in your own configuration.
And, I hope you'll appreciate it, the updated manual again!
enjoy
GHO

[gho]

v2.02.24

News in this release:
- many small improvements and fixes, as usual....
- a much better ability to handle primary surface emulation in ddraw games, both using a better capabilities assignement, and using the "preserve surface capabilities" flag: this flag, in practice, makes DxWnd remember the capabilities of any surface before they are altered and to restore them whenever queries by the GetSurfaceDesc method.
- and, just for fun, a black and white screen emulation (working only with ddraw games with surface emulation on and with some color handling - currently it doesn't work for any 32BPP game that is rendered on a 32BPP desktop).

Some of the architectural changes are, again, very promising, so I expect to support better many other games. Let's hope so.

update: the v2.02.24.fix1 fixes a DxWnd crash in the new preserve caps option. Also there are a few things to better run Grand Prix World, I hope several other games could be affected and improved (I noticed that Warlords3 now behaves much better).

[gho]

v2.02.25/26/27

Well, three releases is meant to be a lot of changes, but the details are in the readme.
What are the most interesting ones?
First one is a general code reworking to put all code related to a system dll within the same file. This way, hooking further dlls should be easier and much neat and clean. No visible effect in the final compiled exe, though.
The second one is the beginning of a general rework of the HDC mess caused by gdi32 and ddraw using the same resource. "Warlords 3" now works almost perfectly, showing the text written by gdi OutText on top od ddraw surfaces. Too bad that it still hangs quite easily during the gameplay, but sooner or later I'll fix this one (I hope, at least!).
So, downlad it and have fun!

[gho]

v2.02.31

Ok, I'm on vacation, with a portable XP and a few oldies on a USB HD. So, don't expect news about recent programs: I had to concentrate to some nice oldies, but I assure you it was worth while.
What's new in this release? Well, actually several things.
First of all, the GDI emulation is much better and complete. Now you can play some oldies such as 688 Hunter Killer or Imperialism I & II in the glory of the stretched window size you prefer, or in "Desktop work area" mode. To get this result I had to wrap many different APIs, and I invite you to test other GDI games that very likely will show some glitches and need to fix some other GDI API. Just don't forget to set the GDI emulation flag and, if text is not the right size, the "Scale font parameters" flag.
Then, another area of improvements was in the handling of primary and backbuffer surfaces in the crazy case where a new ddraw session may inherit the backbuffer surface created by the previous one. That depends on the ddraw interface verisons, and required a painful thinking to get something almost satisfactory. The hope is that whenever this mechanism will be emulated well enough, many ddraw options may prove unnecessary. After that great effort, I made Silent Hunter II working pretty well (it's a nigthmare game, actually, involving three different exes that access the screen one at a time!).
Another old glory that was added to the list is Descent 3: this one so far seems to work pretty well in OpenGL mode, but crashes in ddraw (actually it doesn't work very well even in native fullscreen mode!). So it will be WIP for a while.

One last and important news: since the game list has grown past the 256 tasks limit, I had to stop adding entries in the config file and so I created a folder "exports" in the sourceforge portal where I'll plan to post the archives containing the exported configurations of each individual program. You will have to download the export.rar file and extract from there just the interesting configurations, to be "imported" in your DxWnd configuration file and modified at your pleasure.

bye, ;)
GHO

[gho]

v2.02.32

Being on vacation has its advantages: far from my usual environment I had to concentrate on old games that were easily available, so I had the idea to emulate the device context handling pretty much in the same way the directdraw surfaces are.
The idea is pretty simple: each time the program asks GDI or USER32 a DC, dxwnd builds a memory DC whith the screen size and capabilities (it's actually a memory bitmap...) and when the DC is released it stretch-blits it to screen.
This way, you need not to hook every single GDI call related to X,Y coordinates and sizes, because the syntetic DC has the right characteristics for the regular call!
The result is still partial and imperfect, but very promising: I invite everyone to grab a copy of G-Nome and try it using the new dxwnd release and configuration settings.
Apart form that, I tuned the ddraw surface handling and had this crazy "Nightmare Ned" game fully working in emulated mode. Mind you that, despite its childish interface, this game is not easy at all and quite frustrating.
The only sad news is that holydays are almost over.... too bad!
bye
GHO

[gho]

v2.02.34

A lot of exciting news: I quote from the readme

CORE: Much better surface description in log Completely revised CreateSurface hook: emulated and direct code are merged as much as possible, and reference counter are kept accurate. Now most games can work both in emulated and direct mode.
Fixed surface capabilities for "Vangers", "The Sims" (now working in emulated mode again) Updated "Fixed aspect ratio" option: now uses the x,y size declared in the configuration instead of the fixed 800 x 600 standard one.
Added virtual fullscreen "Desktop" mode.
Completely revised the Peek/GetMessage handling: now it uses the standard SetWindowHook API instead of the address redirection, making the handling more reliable and accurate: now "Age of Empires III" works at last! GUI: Added virtual fullscreen "Desktop" mode.
Added "Fix buffered IO after Win98" flag: this is meant to fix an incompatibility in the ReadFile kernel32 API that must read from block boundaries, where a block was smaller up to Win98 and bigger after it. As a result, games like "Dylan Dog Horror Luna Park" show IO errors while reading data from the CD. Unfortunately, this is not the only problem of this game, so Dylan Dog fans will have to wait further. Maybe some other programs suffer of this problem, and I will strongly appreciate if anyone finds some.

But, to me, the most exciting news is that now, with the revised surface handling and changed default parameters, an impressive amount of games work just with the default configuration! Then, it's up to you to fine tune it. Enjoy, and forgive some regression bug that is there for sure.