"Actually, Alex provides a general technique for calling any 32-bit Ring 0 (privileged)
code from a normal Ring 3 (under-privileged) Windows program."
- Andrew Schulman
"..some of the most clever software engineering I have ever seen!"
Few programs from these samples rely on Ringo,.a technique to dynamically load and unload VxDs that I invented
at the end of 1992. At that time Windows 3.1 was ruling the world of PCs, VXDLDR has not been anywhere around,
and there was no official way to load and unload a VxD other than to modify the SYSTEM.INI file and reboot. Andrew Schulman's generic VxD, VXD.386, a wonderfully inspiring piece of software, gave me enough motivation to work on
Ringo. This technique has proven to be very stable, and although this wasn't even contemplated, it works on all
Windows platforms with VxD-based kernel model, from 3.0 to Windows 95. At the time of this writing, it works flawlessly
on Memphis (Windows 98, beta 2) as well.
Starting in Windows for Workgroups 3.11 and on to WIndows 95, the system comes with the new component called VXDLDR. This a VxD loading device, and it's a VxD itself. VXDLDR provides a defined and documented interface to load and unload other VxDs on the fly, so technically speaking, using Ringo is no longer necessary. But if nothing else, Ringo is the only technique I'm aware of, which lets you combine a Windows application, a DOS program, and a VxD, all within bounds of a single executable file!
The main idea of Ringo is to combine sections of code that are to run at different CPU privilege levels and with different bitness, within a single Windows executable module, EXE or DLL, thanks to the 16-bit linker who doesn't care about that, and to resolve all necessary fixup references at run-time. To get an initial hit on its VxD segment, Ringo also constructs a call gate, the type of system selector, available on Intel 80x86 CPUs but not directly supported by Windows. Ringo was originally implemented as RINGO.DLL, and the details of the technique were published in the March 1994 issue of the Dr. Dobb's Journal. The DLL has been greatly enhanced since then, hence the new name: RINGO2.DLL. One important difference from the original version is that there is really no need to use vendor-specific (and undocumented!) API to get to the CPU descriptor tables, which is needed to construct the call gate. Check this technical note on SLDT instruction to find out why and how.
A few programs found here require RINGO2.DLL to be present in your load path
In order to run them, download RINGO2.ZIP and place the DLL in your Windows directory.
This page has been visited times since Mar-24-1998