Here's my collection of small programs I wrote, mostly command-line for Win32 and DOS.
I don't feel like making a bunch of seperate pages for these ones.
Everything comes with the source and binaries are included that were compiled with Open Watcom, unless noted.
A global message hook DLL that offers AutoScroll & Pan function on the middle mouse click.
It can call EnterReaderModeHelper from user32.dll or use my highly modified reader.c that was in the leaked WinXP source. *(NT\windows\core\ntuser\client\reader.c)*
The modified code can also read settings from a .ini file, which define how to treat certain window/control classes and some global flags.
Also Win9x specific functionality about hooking the mouse wheel is also included that can be compiled in, it's way more efficent that way than loading 2 seperate DLLs and installing multiple hooks.
This code in its own DLL can be found in Hijack-MouWheel9x below.
This works on Windows 95/NT4. (support for NT3.51SP2 is quite limited but loads fine)
Coming soon. (original portions of reader.c code is © 1985-1999 Microsoft Corporation)
64-bit version compiled with GCC will also be available.
A global message/mouse hook DLL that allows the mouse wheel to be hooked by AutoHotkey, it uses message 0x1410 and can partially block mouse clicks (pathetic workaround for IntelliPoint limitations).
The Win98 version (and NT4, but this is not verifed) doesn't rely on IntelliPoint as it intercepts the WM_MOUSEWHEEL messages.
The Win95 version (and NT3.51, also not verified) needs the IntelliPoint (3.0) drivers to work, it basically is a dumb crude remake of mswheel.dll AND I did not tested this code yet, I only assume that it works.
(I think that checking if the HIWORD of dwExtraInfo equals 0x4001 is enough but mswheel.dll does so much more than that)
Coming soon.
This is a DLL designed for AutoHotkey, but could be useful in other applications.
In Win9x the function SetWindowLong has not effect on a window that belongs to another process, this DLL can workaround this limitation by installing a message hook for the target window.
It can only hook a single thread but suggestions are included on how to extend the code to support more.
Using it is basically loading it, hooking the target, maybe using GetWindowLong and then post the registered message "WM_SETWINDOWLONG9X" with the index in wParam and new value in lParam to perform the SetWindowLong in the context of the target window.
Download the ZIP here.
This just sends out bytes to a MIDI port, each command is it's own executable and this is for both Win32 (30KB) and DOS (12KB, direct access to MPU-401 interface).
Loading and playing a .MID file with a fully featured (and big) MIDI player for such purposes can be quite cumbersome, this just sends out bytes without initializing any kind of timers and showing a UI on screen.
The included commands are for the Dreamblaster X2 and my own MIDI-Reset controller.
Download the ZIP here.
Designed for AutoHotkey (windowless) but a command-line version is also available.
This allows to query if a certain device is currently connected or to be more accurate it takes 1-2 arguments which is the DeviceClass name and a search string to filter out the entries and the return value is the number of found matches.
This for example can tell if a certain USB or Cardbus device is connected.
This runs on Windows 98/2000 and newer.
Download the ZIP here.
Nothing special, this just calls the function GetClipboardFormatName for values 0xC000-0xFFFF and outputs the names to STDOUT.
Can be interesting to see what data can be extracted from that. One could may tell which applications are currently running.
Download the ZIP here. (Win32)
I'm confident that this (cres.exe) is the best Win32 command-line tool for changing the resolution.
It's designed to work from Win95/NT4 (maybe NT3.5 too) and has a sophisticated parser for the desired resolution.
It supports multi-monitor setups in Win2000 (not Win98 as I gave up due to driver issues).
It is one of the very few tools that allow to set a desired refreshrate in Win9x and this is done via registry access and features clever workarounds to only change the refreshrate while keeping the resolution.
My main resolution of 1600x1200 with 32bpp at 160hz is written as "1600x1200@32:160".
However, the parser is flexible and is very capable of taking the parameters in any order, so "800:160@32x600" is equivalent to "800x600@32:160" and even better it queries the current resolution and uses that data to fill in the remaining gaps.
I can switch my 15khz output from the 4:3 "768x576" to the 16:9 "1024x576" by just running "cres 1024".
Same can be done for the refreshrate, I can switch my main screen to 120hz by only running "cres :120".
Also '-' is a escape character that allows for placement of the horizontal resolution value after another number and allows "x768:85-1024@16" to be equivalent to "1024x768@16:85".
It also features a unique 'test for 15 seconds' mode where it switches back to the previous resolution after the countdown has reached 0. Just add a '?' to the resolution to enable that.
There are other flags that can be enabled by adding the corresponding character to the resolution.
Download the ZIP here.
This "screensaver" starts another screensaver depending on the current Hardware profile.
It is easy to setup. Set it as your Screensaver in the Windows control panel and use the user friendly settings dialog of that to define which Screensaver should start under which HW-Profile.
Resource Hacker can be used to translate this program without compiling a new version.
Both ANSI and Unicode versions are available, as well as a German translation.
This runs on Windows 95/NT4 and newer.
Download the ZIP here.
That file contains a bunch of XORed .PCX files (for load, event, credits screens and backgrounds).
PCX files usually have a lot of zeros in their header making them easy to detect.
Download the ZIP here. (DOS/Win32)
These files contain several other XORed files stored in a archive format with names up to 8 characters. The format was easy to figure out just by looking at that with an hex editor.
Download the ZIP here. (DOS/Win32)
I wanted a simple and quick way to correct the checksum on PC ROMs or else the BIOS won't execute them.
So I spent some time searching on the net for one but after 10 minutes I figured that I'll could write my own faster than I'll could find a good one. So in the end I just did, which explains the humorous error messages.
This should work with any size, it will change the last byte of the file to make 8-bit checksum match 0x00.
Download the ZIP here. (DOS/Win32)
I got inspired to write this after looking at the disassembly of TRSIBM.CO for the Tandy 200 (which you can find in M100SIG/Lib-10-TANDY200).
The provided default tables are for converting special characters to ANSI and for Codepage 850 (I think).
The table consists of byte pairs and mustn't exceed 512 bytes. This program will swap found characters around in both orders, so the first match found in the table will be used.
I mostly use this to correct ÄÖÜ and ß in textfiles written on my Olivetti M10.
Download the ZIP here. (DOS/Win32)
Now this is more like a package for an simplistic WinNT Shellextension but it comes with one super tiny program that has like 32 effective lines of C code which just rediects a COM port to STDOUT but strips out CR (0x0D) and terminates at EOF (0x1A). Support for Win9x will be available soon.
This adds handy functions to the Windows Explorer contextmenu for easy and simple textfile transfer from Model T Laptops over serial.
Download the ZIP here. (installation instructions and support files)
This is used to the create the BASIC DATA statements for my HOTKEY.BA versions.
This takes a binary file with the assembled code and a logfile containing the STDOUT of the A85 cross-assembler along with the special print commands.
The logfile should contain markers on addresses to be relocated by the actual installer run on the Laptop, as well as the gaps between the REM lines.
The output will contain the DATA statements with line numbers and the REM placeholders to store the installed code at the end.
Download the ZIP here. (DOS/Win32)
I wasn't impressed with the performance of all available Model T BASIC tokenizers (even the built-in one inside VirtualT).
None of them worked so flexible as the one used by the Model T BASIC internally.
What I mean with that is the way how lines out of order, duplicate ones and even empty* program lines are handled.
I wrote this to mimic the way how the Model T does it but with the processing power of an "modern PC".
The code is sure a mess but I didn't encountered any issues with my tests, except when I made the 16-bit version. It was a dumb compiler bug but managed to find a workaround by accident while debugging with printf().
This takes a ASCII textfile containing the BASIC program and optionally a keyword file in the Tandy format.
Keyword file for the Tandy (same as Olivetti M10) named KEYWORDS.bin (default name) and another one for NEC named KEYW-N82.bin are included.
*BASIC line with just the linenumber but no statements
Download the ZIP here. (DOS/Win32)
