This will be a "suffered" release because of the many aborted attempts to improve. But in effect the final result should be little more that the previous release, but some important bugs fixed and some cleaning up.
So, just because this ought to be not a wonder but a more stable one, I'm posting here all files before pushing them on the SF download area.
To explain in short the most notable changes respect of the latest betas, this one should have:
- proxy mode hooking working better (the last release were crashing the GUI!)
- a better handling of ddraw close, avoiding at the same time leakages (like 2.05.82) and crashes (like 2.05.83)!
- an internal rework that, hopefully, should produce no damages
- help files aligned to last fixes
- support for Windows XP RTM (if any copy still exists in the damned world)
then, what's still missing:
- a merged exception handler able to do the best of DxWnd current handling and MS shim handling
if anyone would like to test InjectAPC hook mode, please remember that the dll must be extracted from the AV-shielding archive.
If there's nothing wrong (I mean, nothing NEW and wrong) these files will be uploaded as they are.
i wish to be the bearer of good news, but there are DDraw problems still. I am still unable to emulate you and huh's result in games, for which I have to revert to. 82 or older, while yours work fine in. 83fx2. That is, this release is unusable to me, because almost all games requiring special tweaks to the configuration with DxWnd fail, most of them crashing or "The memory location xxxxxx referenced memory..." errors.
Dark Secrets of Africa is currently the best example (just like Happy Land X-Mas Adventures), you can compare the length of the two logs too, finding that DSoA crashes way early.
@gho
Unfortunately, Dark Secrets of Africa no longer works with this version for me. The game crashes on startup with Hot patch. This also does not work with Inject DLLs°°. Something must have broken.
°°Update:
but this problem is not new already existed in version 2.05.82, new is the problem with the Hot patch.
Update2:
It stopped working for me in version dxwnd.2.05.84.ie2.rar
Last edit: huh 2022-05-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ach, quite a lot of complains! Well, at least I was right not to post the bundle straight away. Let's see if I can fix some.
The crash in Windows XP RTM shows an address that could be related with this operation:
It is about trying to manage the DxWnd icon in the taskbar, but it is possible that the whole mechanism is not supported there. I should get a Windows XP RTM machine to test. Anyone could suggest (through PM, please ...) where to get a disk image for such an old and rare OS?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For legacy Windows XP testing I suggest using Oracle VirtualBox because it will have a more modern CPU instruction set available. If you are using PCem or a very old real PC the CPU instruction set can be quite limited. For example Dxwnd probably relies on at least SSE2 instruction set which started to become widely available sometime after the year 2003.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also Visual Studio 2008 (which Dxwnd is compiled with) has a minimum host operating system requirement of Windows XP SP2. The newer the compiler the less likely the executables produced will work on older operating systems. For example if I want to compile a test program for Win9x I need to use an older version of MinGW. For sure VS2008 can not produce Win9x compatible executables but it might also have trouble with WinXP RTM.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have tested Winxp on multiple systems and while most work fine, one VirtualBox machine with SP1 or RTM couldn't run it. Neither PCem could. So I asked gho about the system requirements.
Anyways it is available in archive org
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As dippy dipper said, you may want to test on pcem because VMware or VirtualBox will mostly be able to run DxWnd on Windows XP, it is just the old XP supported hardwares causing issues. You may recall I provided you with test results for Dylan Dog on XP SP1, it was from VMware.
Or maybe id there's instructions requirement as he said, such as SSE2 or mmx, it could be useful to let it to be known. The first place where DxWnd actually didn't work was a Pentium 400MHz CPU, and I emulated the same PCem CPU either where it crashed
Last edit: BEEN_Nath_58 2022-05-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The first place where DxWnd actually didn't work was a Pentium 400MHz CPU, and I emulated the same PCem CPU either where it crashed
Well that is not a surprise. I would not expect those legacy CPU's (emulated or real) to be able to run Dxwnd and I don't think it is reasonable/possible to try and support them in the future either. There is a lot of optimization that happens when a program is compiled and also some components of Dxwnd may rely on SSE/SSE2 to function.
So if you want it in a written form I would suppose the minimum hardware requirements for Dxwnd is a CPU model from circa 2004-onwards with SSE2 support. However determining minimum system requirements is not that easy as there are so many different hardware combinations and instruction sets that have evolved over time. Usually a developer simply test the program on older hardware and makes a guess as to what might be the minimum hardware to run the program.
P.S.
I have a PC magazine from December 2000 and in it there is a list of available CPUs in the market at that time. These range from AMD K6-2 (500Mhz) in the low end to AMD ThunderBird at 1200 Mhz at the top. The Intel Pentium III models range from 600-1000 Mhz. So a 400 Mhz CPU for Windows XP seems quite antiquated and obsolete. That said Wikipedia seems to list 233Mhz as a minimum for WinXP which seems quite ridiculous. I remember my WinXP PC from 2002 already had a 1733Mhz Athlon XP in it.
Last edit: dippy dipper 2022-05-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
dosbox X can emulate Pentium 3 CPU. Seeing DxWnd doesn't run on Pentium 2 or first celerons, there's two things I can assume to be the issue, CPU speed or instructions. Some softwares while being compiled had the option to enable or disable certain instructions of CPU, probablt DxWnd wasn't designed that way.
Also I could try on Dosbox-x by installing 98 se first then upgrading to xp but I wonder if any issues will recur.
233MHz isn't the minimum requirements either. XP even works on a 486 machine.
Last edit: BEEN_Nath_58 2022-05-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Note that Pentium 3 only supports SSE. If Dxwnd requires SSE2 then that would be Pentium 4. Similarly the first AMD CPU to support SSE2 would be Athlon 64.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
?
Because I get it with Dark Secret with version v2_05_84_build.rar . With version v2_05_83_fx3_build.rar it seems that I always get 1. Does it matter or does it affect my crash with v2_05_84_build.rar?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The id is the ordinal number of the game configuration and should correspond to the position (starting from 0) of the game entry, or the number shown in "Target #" minus one in the upper-left corner of the modify panel. A position 0 should mean that the game is configured as first in the list, while -1 is used for the proxy configuration.
Maybe you simply had the game in different positions of the two DxWnd configuration?
P.s. when making tests whith multiple configurations for the same game, sometimes DxWnd could pick the first available one instead of the one where you sent the run command. To avoid troubles, it is always a good rule to let a single configuration for a target, maybe using exports to swap different configurations.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the explanation, I'm trying to find a difference in the protocols. So now I know it has no effect. The errors in the logs from versions 2_05_84_build.rar and v2_05_83_fx3_build.rar seem the same, yet the game with v2_05_83_fx3_build.rar works...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Uhm... there was a tricky change that seemed to have no effect, but you never know .... try this and see if it makes any difference. The change is in the hot-patch hooking.
Nothing still works for me. Whatever changed, was from 2.05.82 to .83 release only. Things are breaking gradually, probably it's time to fallback to every updates after 05.82
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@gho
The error came with version dxwnd.2.05.84.ie2.rar for me. If I'm looking right the previous version was dxwnd.2.05.83.ignoreexception.rar (probably it should have been called dxwnd.2.05.84.ignoreexception.rar) and here it works. It must make a difference between the two versions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@ghotik My problem started in the two Handle Exceptions changes in the thread "Handle Exceptions vs Ignore Exceptions". When you decided to make a way to get better logs, the problems started. The patch on 27th April works, but the one from 28th April doesn't.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Let's try to split the problem in two:
Release 2.05.84 contains a few important fixes and a dangerous source code rework. I hoped to release all together, but the code rework seems to be the responsible for the troubles, in particular when you mix early hooks (like "Inject DLL") and "Hot patch" hooking.
Here in attach a version that I baptized as 2.05.83.fx4 because it is the previous stable 2.05.83.fx3 plus the few important changes. Sooner or later I'll catch the flaw in the rework, but for the moment let's privilege stability and reliability.
Does this work better?
I got and fixed a serious bug.
This is my comment in the source code:
// v2.05.83.fx4: Fix. Found on "Dark Secrets of Africa". When closing the previous// ddraw session the backbuffer was not explicitly released, but that happened // automatically because of ddraw version == 4. So, when arriving here the // lpDDSBack->Release() operation was attempted against a unreferenced surface that// has NULL methods and causes an exception.// Better yet (to be done) would be to unreference the backbuffer of a closed ddraw // session when version >= 4 so that GetBackBufferSurface would return NULL.
Now the game starts here with no troubles. I didn't understand yet why the old releases didn't show this problem, maybe because of the leakage that was fixed and that was keeping (by mistake) a valid backbuffer surface.
Anyway v2.05.83.fx4 + the attached fix (that I will silently merge in a new v2.05.83.fx4 for the upload) seems working really good, at least in the video modes that I usually configure for testing.
This will be a "suffered" release because of the many aborted attempts to improve. But in effect the final result should be little more that the previous release, but some important bugs fixed and some cleaning up.
So, just because this ought to be not a wonder but a more stable one, I'm posting here all files before pushing them on the SF download area.
To explain in short the most notable changes respect of the latest betas, this one should have:
- proxy mode hooking working better (the last release were crashing the GUI!)
- a better handling of ddraw close, avoiding at the same time leakages (like 2.05.82) and crashes (like 2.05.83)!
- an internal rework that, hopefully, should produce no damages
- help files aligned to last fixes
- support for Windows XP RTM (if any copy still exists in the damned world)
then, what's still missing:
- a merged exception handler able to do the best of DxWnd current handling and MS shim handling
if anyone would like to test InjectAPC hook mode, please remember that the dll must be extracted from the AV-shielding archive.
If there's nothing wrong (I mean, nothing NEW and wrong) these files will be uploaded as they are.
i wish to be the bearer of good news, but there are DDraw problems still. I am still unable to emulate you and huh's result in games, for which I have to revert to. 82 or older, while yours work fine in. 83fx2. That is, this release is unusable to me, because almost all games requiring special tweaks to the configuration with DxWnd fail, most of them crashing or "The memory location xxxxxx referenced memory..." errors.
Dark Secrets of Africa is currently the best example (just like Happy Land X-Mas Adventures), you can compare the length of the two logs too, finding that DSoA crashes way early.
Last edit: BEEN_Nath_58 2022-05-06
Misc changes, you put ACP over APC in the injectAPC.txt file and other typos, they are fixed here:
*still crashes
Edit: The appcompat.txt file of crash is attached.
Last edit: BEEN_Nath_58 2022-05-06
@gho
Unfortunately, Dark Secrets of Africa no longer works with this version for me. The game crashes on startup with Hot patch. This also does not work with Inject DLLs°°. Something must have broken.
°°Update:
but this problem is not new already existed in version 2.05.82, new is the problem with the Hot patch.
Update2:
It stopped working for me in version dxwnd.2.05.84.ie2.rar
Last edit: huh 2022-05-07
Ach, quite a lot of complains! Well, at least I was right not to post the bundle straight away. Let's see if I can fix some.
The crash in Windows XP RTM shows an address that could be related with this operation:
It is about trying to manage the DxWnd icon in the taskbar, but it is possible that the whole mechanism is not supported there. I should get a Windows XP RTM machine to test. Anyone could suggest (through PM, please ...) where to get a disk image for such an old and rare OS?
For legacy Windows XP testing I suggest using Oracle VirtualBox because it will have a more modern CPU instruction set available. If you are using PCem or a very old real PC the CPU instruction set can be quite limited. For example Dxwnd probably relies on at least SSE2 instruction set which started to become widely available sometime after the year 2003.
Also Visual Studio 2008 (which Dxwnd is compiled with) has a minimum host operating system requirement of Windows XP SP2. The newer the compiler the less likely the executables produced will work on older operating systems. For example if I want to compile a test program for Win9x I need to use an older version of MinGW. For sure VS2008 can not produce Win9x compatible executables but it might also have trouble with WinXP RTM.
I have tested Winxp on multiple systems and while most work fine, one VirtualBox machine with SP1 or RTM couldn't run it. Neither PCem could. So I asked gho about the system requirements.
Anyways it is available in archive org
Windows XP RTM is available here:
http s://archive. org/download/windows-xp-rtm/Windows%20XP%20RTM.iso
As dippy dipper said, you may want to test on pcem because VMware or VirtualBox will mostly be able to run DxWnd on Windows XP, it is just the old XP supported hardwares causing issues. You may recall I provided you with test results for Dylan Dog on XP SP1, it was from VMware.
Or maybe id there's instructions requirement as he said, such as SSE2 or mmx, it could be useful to let it to be known. The first place where DxWnd actually didn't work was a Pentium 400MHz CPU, and I emulated the same PCem CPU either where it crashed
Last edit: BEEN_Nath_58 2022-05-07
Well that is not a surprise. I would not expect those legacy CPU's (emulated or real) to be able to run Dxwnd and I don't think it is reasonable/possible to try and support them in the future either. There is a lot of optimization that happens when a program is compiled and also some components of Dxwnd may rely on SSE/SSE2 to function.
So if you want it in a written form I would suppose the minimum hardware requirements for Dxwnd is a CPU model from circa 2004-onwards with SSE2 support. However determining minimum system requirements is not that easy as there are so many different hardware combinations and instruction sets that have evolved over time. Usually a developer simply test the program on older hardware and makes a guess as to what might be the minimum hardware to run the program.
P.S.
I have a PC magazine from December 2000 and in it there is a list of available CPUs in the market at that time. These range from AMD K6-2 (500Mhz) in the low end to AMD ThunderBird at 1200 Mhz at the top. The Intel Pentium III models range from 600-1000 Mhz. So a 400 Mhz CPU for Windows XP seems quite antiquated and obsolete. That said Wikipedia seems to list 233Mhz as a minimum for WinXP which seems quite ridiculous. I remember my WinXP PC from 2002 already had a 1733Mhz Athlon XP in it.
Last edit: dippy dipper 2022-05-07
dosbox X can emulate Pentium 3 CPU. Seeing DxWnd doesn't run on Pentium 2 or first celerons, there's two things I can assume to be the issue, CPU speed or instructions. Some softwares while being compiled had the option to enable or disable certain instructions of CPU, probablt DxWnd wasn't designed that way.
Also I could try on Dosbox-x by installing 98 se first then upgrading to xp but I wonder if any issues will recur.
233MHz isn't the minimum requirements either. XP even works on a 486 machine.
Last edit: BEEN_Nath_58 2022-05-07
Note that Pentium 3 only supports SSE. If Dxwnd requires SSE2 then that would be Pentium 4. Similarly the first AMD CPU to support SSE2 would be Athlon 64.
@gho
I have a question. What it means in the log
?
Because I get it with Dark Secret with version v2_05_84_build.rar . With version v2_05_83_fx3_build.rar it seems that I always get 1. Does it matter or does it affect my crash with v2_05_84_build.rar?
The id is the ordinal number of the game configuration and should correspond to the position (starting from 0) of the game entry, or the number shown in "Target #" minus one in the upper-left corner of the modify panel. A position 0 should mean that the game is configured as first in the list, while -1 is used for the proxy configuration.
Maybe you simply had the game in different positions of the two DxWnd configuration?
P.s. when making tests whith multiple configurations for the same game, sometimes DxWnd could pick the first available one instead of the one where you sent the run command. To avoid troubles, it is always a good rule to let a single configuration for a target, maybe using exports to swap different configurations.
Thanks for the explanation, I'm trying to find a difference in the protocols. So now I know it has no effect. The errors in the logs from versions 2_05_84_build.rar and v2_05_83_fx3_build.rar seem the same, yet the game with v2_05_83_fx3_build.rar works...
Uhm... there was a tricky change that seemed to have no effect, but you never know .... try this and see if it makes any difference. The change is in the hot-patch hooking.
Unfortunately, this is not it, the game still crashes with a memory error. It must be something else...
Nothing still works for me. Whatever changed, was from 2.05.82 to .83 release only. Things are breaking gradually, probably it's time to fallback to every updates after 05.82
@gho
The error came with version dxwnd.2.05.84.ie2.rar for me. If I'm looking right the previous version was dxwnd.2.05.83.ignoreexception.rar (probably it should have been called dxwnd.2.05.84.ignoreexception.rar) and here it works. It must make a difference between the two versions.
I replicated the problem. It's a tricky one, please be patient. Anyway, thanks, I think I can go on now.
@ghotik My problem started in the two Handle Exceptions changes in the thread "Handle Exceptions vs Ignore Exceptions". When you decided to make a way to get better logs, the problems started. The patch on 27th April works, but the one from 28th April doesn't.
Let's try to split the problem in two:
Release 2.05.84 contains a few important fixes and a dangerous source code rework. I hoped to release all together, but the code rework seems to be the responsible for the troubles, in particular when you mix early hooks (like "Inject DLL") and "Hot patch" hooking.
Here in attach a version that I baptized as 2.05.83.fx4 because it is the previous stable 2.05.83.fx3 plus the few important changes. Sooner or later I'll catch the flaw in the rework, but for the moment let's privilege stability and reliability.
Does this work better?
NO :(
Also update your injectAPC.txt, you made mistakes there, also the infamous "ACP spelling"
@gho
Sorry, Dark Secret is still crashing. Maybe you missed something, a little thing, I don't know...
Spystudio says
Previously, there were some exceptions to msvcrt.dll
Last edit: huh 2022-05-08
I got and fixed a serious bug.
This is my comment in the source code:
Now the game starts here with no troubles. I didn't understand yet why the old releases didn't show this problem, maybe because of the leakage that was fixed and that was keeping (by mistake) a valid backbuffer surface.
Anyway v2.05.83.fx4 + the attached fix (that I will silently merge in a new v2.05.83.fx4 for the upload) seems working really good, at least in the video modes that I usually configure for testing.