Due to changes in the base OS DP4 does not work as well on Windows Vista as on previous releases of Windows and may require configuration file changes to work at all. In the name of security, Microsoft have chosen to remove important functionality that DP4 depends on. There is very little we can do about this. New versions of some components and some new DP4 components are available that address some problems that affect users running DP4 on Windows Vista, or through a remote desktop connection on Windows Server 2003..
DP4 is intended to run as a service, but could not do so on Windows Vista RTM in its original state. DP4 can still run fairly well as an application on this release. It appears that DP4 can run as a service on Windows Vista in its current state, though we do not know whether this applies equally to all editions. To run DP4 on the original version of Vista two changes are required in dp4.ini. In the [win32] section, specify a null value for namespace like this:
[win32]
namespace=
In the same section, change the loader string to start DP4 as an application instead of a service:
loader=srvw32.exe -load
Once these changes have been made DP4 will run normally. However, there will be problems if a DP4 application is running in one desktop, and then you use fast user switching to create another session and try running a DP4 program in that session. Do not make these changes unless they prove necessary.
Microsoft have made it difficult to start and stop services. "net start" and "net stop" and the "sc" command seem always to give "access denied" errors, even when you run as an administrator. There are probably ways of fixing this, but we do not know what they are as yet. This prevents DP4 applications from "auto-loading" the DP4 service [28 Nov 2007 This appears to be fixed now, at least if you run in an account with local administrator privileges, and have disabled User Access Control]. It would be necessary to run DP4 as an automatically started service on Vista. DP4 based systems frequently use scripts that stop and restart DP4 over-night. Such scripts will not work on Vista.
Services cannot interact with the desktop at all. So if you try to run DP4 as a service you will not see the "blue diamond" in the taskbar notification area, and you will not be able to view the error log interactively. This does not actually prevent DP4 from running as a service, but does mean that diagnostics from DP4 applications (as opposed to diagnostics from the DP4 service) will not be written to the DP4 error log, and that viewing the DP4 error log, or stopping DP4 is more difficult. Stopping the DP4 service no longer causes DP4 applications to close down gracefully, because DP4 cannot broadcast the "DP4 stopping message" to applications. It is possible to capture DP4 diagnostics from applications by provding the application with a valid "stdout", either by redirecting the output of the application to a file, ior by using kentcurs to set the application to be a "console" application. The latter may be more useful if you want to ascertain the exact moment that a problem arises, but will be confusing to end users. An update to DP4 is available to address these issues. A per-session program called dp4tray is available, which will indicate whether or not the DP4 service is running normally, and which will allow the error log to be viewed interactively, and the DP4 service to be stopped and restarted, and notifies running applications when DP4 is being shut down. In addition there is a new server component errpipet.w32, which will capture DP4 diagnostic output from DP4 utilities that are unable to communicate with errlog.w32 in the normal fashion. This component should be started in the appropriate [startup] section of dp4.ini.
28 Nov 2007. The contents of this paragraph no longer appear to be true. On Vista ordinary applications cannot create global shared memory. DP4 normally uses global shared memory for communication between applications and the database manager (As far as we can tell from Microsoft's documentation this is an approved way of doing IPC, but Microsoft seem to expect that the service end should create the memory). Currently each DP4 application creates its own area of shared memory so that applications are not limited by having to wait for a particular piece of shared memory to become available. This approach is no longer possible. Either srvw32.exe would have to create as many blocks of shared memory as might be required (thus wasting memory most of the time), or we would have to devise some complex method of getting the DP4 service to allocate memory for applications as it was required.
The additional security, particularly the new "User Access Control" feature is likely to confuse end-users considerably. You can expect problems with any scripts that perform "administrative" type tasks, such as installing upgrades, performing backups and so on. You can also expect problems if you use tools such as VNC or PC Anywhere to gain access to remote desktops, and will probably need to get updated versions of such tools.
6 Jun 2008 We have recently become aware of an issue with DFPRINT, which, so far as we know, is confined to Windows Vista. The issue is as follows: if the user selects the "Print" button, but then cancels the Windows printer selection dialog that appears and then exits DFPRINT, then DFPRINT does not actually terminate. In fact the issue only arises when DFPRINT is run "locally" : if run via a remote desktop connection there is no problem! We do not yet know if the problem is fixed by Service Pack 1 of Vista.