If you install Windows XP SP2 on a machine with one of the above releases of DP4 for Windows installed, DP4 will usually, but not always crash when you try to start the DP4 service. This problem has been caused by changes made to undocumented features of Windows that software protected with anti-debug measures, including various sensitive DP4 components, commonly rely on. (See detailed explanation below if interested)
You can find patches for this problem for each of the above DP4 releases in the download section at the bottom of this article. The full ZIP download for each DP4 release has also been updated. There is no need for users of other releases of Windows to upgrade their DP4 software. Only Windows XP SP2 is affected at this time, though it is possible that future service packs for Windows 2000 or Windows 2003 may also be afflicted.
The Windows XP firewall may well stop network software from working. If you are using DP4 networking,and want your machine to act as a server, and you turn on the Windows XP firewall you will need to configure it to open port 5000, or your chosen port for DP4 networking. (See DP4 Networking and Port 5000 for reasons why you might want to use another port for DP4 networking between Windows XP machines).
Note: Although Windows XP firewall has a checkbox about displaying a notification when it blocks a program from using the network, it only displays this for TCPMGR if you load DP4 as an application. If DP4 is loaded as a service it simply fails silently.
Windows XP SP2 has something called DEP "Data execution prevention", designed to stop various exploits due to buffer over-run. It is surpising that this is considered a new feature, as the Windows memory protection APIs have always clearly distinguished bettween executable and data memory. However, if this is genuinely only implemented for the first time,it will undoubtedly cause a lot of problems to existing applications. Probably MS have tested various popular applications and have added some magic compatibility flags to the registry for them. But if you happen to be using an application not on their approved list, you may well have problems.
This explanation is fairly technical, and there is no need to read it, but if you have other software which mysteriously crashes after you install Windows XP SP2, it may help the suppliers of that other software if you communicate it to them.
In Windows XP Service Pack 2 Microsoft have made some changes to some very fundamental structures are loaded in memory. The two structures are known as the Thread Information Block, and the Process Information Block, or TIB and PIB for short; sometimes they are also referred to as the Thread Environment block and the Process Environment Block (TEB or PEB).
In all previous versions of Windows NT familiy operating systems, right up to 2003 and XP Tablet PC edition, these particular structures are at fixed addresses, and by looking inside the structures they point to you can discover various interesting facts, such as whether somebody is trying to hack you, and what version of Windows is being used. It is the only way to do this without having to call a Windows API, which is something hackers can easily spot and neutralise. Therefore software that contains anti-hacker defences for licence checking, copy protection or encryption code, commonly uses these structures to try to defeat hackers. (In fact this used to be documented in MSDN, but the relevant article has been removed). Programs actually find these structures by looking at certain offsets within the memory segment pointer to by the FS segment register. On Windows 9x these structures are at different addresses, whereas they have always been at addresses 0x7ffde000 and 0x7ffdf000 in Windows NT family operating systems. Programs with anti-debug code use this to check the version of Windows that is being used, because the memory location that indicates the presence of a debugger is different parts of these structures in Windows 9x and Windows NT.
Unfortunately the same structures also contain important information about the privileges of the user running the program, and it is apparently an easy matter to elevate privileges by fiddling with these structures. So some hacker exploits and viruses may depend on buffer over-runs that write into this part of memory, and these will probably be coded for these fixed addresses.
In Windows XP SP2 these structures are therefore located at a fairly random address, in the hope of defeating these exploits. Programs with anti-debug code may well believe they are running on Windows 9x, and hence check for the presence of a debugger in the wrong memory location, and because the memory location does apparently indicate a debugger, they will invoke their anti-debug code and probably fail deliberately in some way.
This is what happened to DP4: though it does not rely on the fixed address technique, its anti-debug code did assume that on NT the addresses would differ by exactly 4096 bytes, so that any other difference between the addresses indicates Windows 9x. The patch contained in the download makes DP4 use a second test in addition to the 4096 byte test, which, so far as we can tell, always works on Windows XP SP2.
Please visit the FTP site for these fixes. For each of the downloads below, unzip the files contained in the zip file into the directory where DP4 executable files are installed. Make sure that no DP4 programs are running, including the DP4 service.
DP4X525PSP2.zip for release 4.525
DP4620XPSP2.zip for release 4.620
DP4621XPSP2.zip for release 4.621
The full DP4 downloads for these and for more recent DP4 releases incorporate this change.