Vlad set out to provide a sound emulation layer for DOS games under WinNT (later Win2K/XP). You cannot say that this goal wasn't met or even that it didn't exceed the original expectation! It's true that many games run only when using VDMSound as part of the total solution. Mouse, video, CPU speed and other hardware also have their own idiosyncrasies and issues. Post development of 2.0.4 several tools appeared in support of these other issues and these were later packaged as part of the 2.1 beta.
I agree that it would be good to revamp the project with fixes/improvements but as far as the original author is concerned his work was done and he has now moved on. VDMSound's remaining lifetime is also 'limited' as Microsoft have removed 16 bit support from the 64bit version of WinXP.
DOSBox is hugely focused and has built up a large following - probably down to the fact it runs games on platforms other than Windows. Unlike DOSBox however, the VDMSound solution no longer has anyone in control of its development. Also progress is only required in the peripheral areas as I outlined (everything else bar sound!) and this is not likely to happen when a project has no team! Feel free to highlight specific areas that need improvement - perhaps a reader may be able to help?!
From another message I posted:
What a coincidence...I have already been putting together a series of fixes to address many of those "peripheral areas" issues. From a marketing perspective I was looking at a "new" product launch to bridge the gap between the performance of the current DOSBOX (v0.63+) emulation on Win32 PCs as compared to the higher speed native emulation of the Win32-NTVDM for the ever popular late-era DOS protected mode games on lesser hardware.
I was going to approach the VOGONs crew about this matter in another month or so, but since the subject has been broached - send me an email (in my profile) and we can discuss off-line. I think that the two products, 'DOSBOX' and the 'fixed NTVDM emulator' environment could complement each other over the next few years. The DOSBOX product is the future for much faster 64-bit based PC workstations, but the 32-bit Win32 base will be where most of the market will remain until the future standard is a (for lack of a better benchmark) roughly a 64-bit 11 GHz processor 😀
My curiosity has been raised as I have scanned the various websites pertaining to the gyrations necessary for the successful execution of older DOS applications and games on the WinNT/2K/XP NTVDM platform. Looking at the Microsoft code it became apparent that most of the technical problems enountered were created by marketing decisions made to encourge the migration to the Win32 and now the Win64 platform. The greatest technical accomplishments necessary for the NTVDM product have already been made in the guise of VDMSound and the DOS/32A DPMI extender. Outside of VCPI based (or proprietary memory-mangement) games, or very badly coded DOS apps/games which break outside of x86 real mode there is no technical reason that say 97% of all DOS games cannot be used with the Win32-NT based operating systems with a combination of DoxBox and the re-launched NTVDM based product.
The remaining Win32-NT problems appear to be VESA video access, mouse problems, DPMI host problems, NTVDM errors, EMS page-frame problems, selective register corruption, multi-processor problems - all the little details that Microsoft 'forgot' to finish over the years. Most of those have been addressed in the fruitful but haphazard use of Tsr/Isr code which correct part of the Microsoft created problems with the NTVDM environment. These technical issues are a hinderence to the average VDMSound user since many go throught the learning process of batch files, 8.3 naming conventions, which TSRs for Video, Mouse and Vesa to use, etc.
I can fix those problems.
The other major problem with the current VDMSound/LaunchPad is that too many variables are left in the hands of DOS novices. The object of the system is to let today's DOS-ignorant individuals play the old DOS GAMES, not become semi-literate in the arcane DOS knowledge necessary to execute them. There are too many batch files, TSRs, load order, nested loaders and switch configuration for the average user. This must stop if the final fixed NTVDM product is to be successful.
When it comes to enhancing/fixing the 'native' NTVDM emulation that Microsoft should have shipped with WinNT4, I think we can do even better and create a superior transparent native WinNT/2K/XP DOS emulation transistion product to complement DOSBOX as the Win32 based operating systems ride off into the sunset. This ride will take some time and will give the newly re-launched product a time to flourish before the inevitable reality of legacy status overwhelms its useful lifespan.
I would be willing to take on the Project Manager position (and do the x86 ASM coding necessary) to create this final "fixed" native Win32 NTVDM environment. The draw would be that legacy DOS Games (and applications) based on varying requirements of EMS, DPMI, Mouse, VESA video such as System Shock, Syndicate Wars would again be easily viable using the x86 V86 mode supported with the native NTVDM environment on the many older, slower x86 PC workstations which will never make the transition to XP-64 or Windows 'Vista'.
This effort would provide a smooth transition to the future as represented by DOSBOX which will required much faster processors to emulate the later DOS DPMI based games with their greater performance requirements. This would represent the 'last hurrah' for the V86 mode NTVDM product before DOSBOX inherits the mantle...
Since future software products require product codenames that "the industry" uses as shorthand for the effort, I propose the codname:
Let me know,