Here is the current selection of programs I have written that I have chosen to make publicly available:
|Program types|| Win32 GUI and Win64 (x64 only) GUI|
Probably requires Windows XP with Service Pack 1 or higher
|Download sizes|| 32-bit version compiled with Visual C++ 6.0: 93,019 bytes |
32-bit version compiled with Visual Studio 2010: 100,706 bytes
64-bit version (x64 only) compiled with Visual Studio 2010: 110,827 bytes
|Download links|| 32-bit version compiled with Visual C++ 6.0: AtariSTPlusPicView115-MSCVER1200-x86.7z |
32-bit version compiled with Visual Studio 2010: AtariSTPlusPicView115-MSCVER1600-x86.7z
64-bit version (x64 only) compiled with Visual Studio 2010: AtariSTPlusPicView115-MSCVER1600-x64.7z
A viewer for most of the popular (and not so popular) Atari ST picture formats. Also supports many Atari TT and Atari Falcon formats and many IFF picture formats. Version 1.14 was the first public release. It was compiled using Visual C++ 6.0, so that it uses no additional Microsoft DLLs that do not come with every version of Windows. The 32-bit version that was compiled with Visual Studio 2010 requires the 32-bit version (x86) of the redistributable MSVCR100.DLL that can be downloaded from Microsoft's site. The 64-bit version compiled with Visual Studio 2010 requires the 64-bit version (x64) of the redistributable MSVCR100.DLL that can be downloaded from Microsoft's site. Anyone who has already installed a program that was compiled with Visual Studio 2010 may already have this DLL (either the 32-bit version or the 64-bit (x64) version or both). I have not tested this program on any versions of Windows below Windows XP with Service Pack 3. I will not include any DLLs in my package. For the Visual Studio 2010 DLLs (both 32-bit and x64 64-bit), do a search on Microsoft's website for the following: Visual Studio 2010 redistributable.
Before sending me any messages regarding this program, please read (in its entirety) the AtariSTPlusPicView.txt file that is included in the .7z file. It can be viewed using an external text file viewer or within Atari ST Plus Picture Viewer itself by choosing Help.
|Program type||Win32 command line|
|Download size||10,603 bytes|
BJWzipFE is meant as a front-end for DOS-based packers that create files in ZIP-compatible format. Using this front-end, the files stored inside the ZIP file will retain their exact names, including capitalisation, including names longer than the 8.3 DOS format, and including names containing spaces. So BJWzipFE adds long filename support to DOS-based ZIP programs.
From a command line, run BJWzipFE without any parameters to get help.
|Program type||DOS16 command line|
|Download size||1,999 bytes|
Calendar performs calculations on dates. I wrote this tiny little program (executable size: 2,585 bytes, and half of that is just text) entirely in assembly back in 1993 and still use it every now and then. Despite the fact that it is a 16-bit DOS program, it runs perfectly from a command line in Windows 95/98/Me/2000/XP. For a given date, it will calculate the day of the week, it calculates the difference in days between two dates, it calculates the dates of Easter for a given range of years, it calculates all Friday the 13ths for a given range of years, and it calculates the resulting date when adding/subtracting a number of days to/from a given date.
Side note: Back when I wrote this program, it made me suspect that every year has at least one and at most three Friday the 13ths, and I then quickly came up with an elegant proof of this fact.
From a command line, run Calendar without any parameters to get help. Alternatively, type "type calendar.com". :)
Just as an exercise, as of early 2012, I have also ported my own assembly version into both C++ and C# code (without using assembly, and compilable as both 32-bit and 64-bit), with a little bit of additional functionality. I am not making this 2012 version publicly available unless people are interested.
|Program type||Win32 command line Linux command line available upon request... and maybe more...|
|Download size||27,870 bytes|
DeflOpt tries to reduce the size of GZIP (extensions .gz and .tgz), PNG, and ZIP files. Regardless of which programs/settings were used to create them, DeflOpt will be able to reduce these files by at least a few bytes more than 95% of the time.
A little bit of history: Back in March of 2003, I finally decided to write something I had been wanting to write for many years: My own ZIP program. So I wrote a program called BJWFlate. However, once I had written it, once I had "solved the puzzle", I quickly lost interest. Every now and then, I still see people looking for BJWFlate. Don't. At the time, BJWFlate was pretty good in terms of making smaller ZIP files than other "zippers" did, but now, several years later, even I myself might not use it anymore if I wanted to use the ZIP format and make a ZIP file smaller than what any other zippers out there do. Back in the day, BJWFlate could compete with (even custom-compiled versions of) 7-zip (in its ZIP mode) and kzip. Since then, kzip has been updated several times and can beat all other zippers (in terms of smallest resulting size) more than 90% of the time.
If you are very stubborn and still want to get BJWFlate, try the following page on Roman Scherzer's site: http://www.clrmame.com/download.htm#zipmax. For historical purposes, as well as because some of the information may still be useful, here is my old page on BJWFlate and DeflOpt. Please keep in mind that several things on that page are outdated and that I have stopped all development on BJWFlate.
DeflOpt is just something I wrote while I was developing BJWFlate. I found that one of the ideas I used in BJWFlate was not used by any other zipper. Even if another zipper could compress a file to a size that was smaller than what BJWFlate did, I could still apply that idea to that other zipper's ZIP file and make it smaller. So while DeflOpt started its life as just a small piece of code within BJWFlate, it survived while the rest of BJWFlate did not.
I have to give an acknowledgement here: When I started writing BJWFlate, I was stuck at some point in my understanding of the Deflate specification. A few email exchanges with Ken Silverman, who was working on kzip at the time, made me understand the one thing I had not understood about the Deflate specification, and so I wrote BJWFlate. DeflOpt grew from that, as mentioned.
Contrary to what I have seen mentioned on some pages, DeflOpt does not just remove garbage from Deflated files, but actually optimises the structures created by Deflate programs and then recodes the files using those optimised structures. It performs a few other tricks too that are not "just removing garbage". It will make a file smaller more than 95% of the time, even if that file was created by a Deflate program that does not generate "garbage", and even if it was created by Ken Silverman's kzip or pngout programs.
DeflOpt should be used as the final step in getting files smaller. First use other programs (I recommend kzip for ZIP files and pngout for PNG files), then run DeflOpt on the resulting files.
I have also seen some people mention the "less than stellar performance" of DeflOpt to make existing files smaller. Yes, it usually shaves only a few bytes off of those files. But that "less than stellar" performance is based on what other programs do to make files smaller. Even if a "stellar program" makes your Deflated file smaller, my DeflOpt is often able to use the exact same structures, but coded differently, to shave off a few bytes. It does not try to use better ways of compressing the original file; it merely copies the exact same way other programs have compressed the file, but still ends up gaining a few bytes by optimising the structures that were used. Once more, DeflOpt is only meant as the final step in making Deflated files smaller. Its "less than stellar performance" still makes files created by "stellar performers" smaller most of the time... . Either way, this is a moot point, since the people rating it "less than stellar" seem not to understand what my program does and does not do or have not bothered to read my explanation of what it does.
Not long after I had released the currently available version of DeflOpt, I made some modifications that would allow it to be compiled using GCC. This meant that native executables of DeflOpt could be made for pretty much every platform. Well, shortly afterwards, after I had announced that here on my webpage, I got into an agreement with someone else who would take over DeflOpt because he "would create Linux executables and maintain the project from then on". Obviously, that never happened. Never heard from him again after a few initial emails and a few emails after I had sent him the source code... . I am ready now (meaning 2012) to take back ownership of my program. Any lawyers around to give me free advice? ;)
From a command line, run DeflOpt without any parameters to get help.
|Program type|| Win32 GUI |
Requires DirectX 7.0 or higher
|Download size||11,453 bytes|
Sorting Demonstration gives a visually attractive demonstration of a lot of different sorting algorithms. As a student, over 20 years ago, I was pretty much being thrown to death with sorting algorithms, so I wrote a much simpler similar program for the Commodore 64 to actually see all those sorting algorithms in action. Then, in 2001, I decided to write a much nicer looking version for Windows. Over the years since then, I have occasionally made additions and improvements to this little project.
In the main menu of Sorting Demonstration, use the up and down arrow keys to go from item to item, and the left and right arrow keys to modify the currently selected item. If a given algorithm's demonstration takes too long for your taste, hit the Escape key and in the main menu, change the number of frames per second and/or the number of frames it actually draws. Note that increasing the scaling factor (which requires a restart of Sorting Demonstration) can also be used to make things faster.
Finally note that in most cases, if Sorting Demonstration takes longer for sorting algorithm A than for sorting algorithm B, then this actually also reflects the difference in efficiencies of those algorithms. There are one or two exceptions, though.
|Program type||Win32 GUI|
|Download size||18,489 bytes|
Zip Manager is a two-pane GUI. Load (or drag) a ZIP file into one pane, load a ZIP file into the other pane (or not). Then manipulate them. Copy files from one ZIP file to the other, delete files within a ZIP file, rename them, and some more things. All without recompression. For people who remember Norton Commander, this program should feel very intuitive. But even for those who don't know Norton Commander, just being able to drag & drop, copy things back and forth, delete, rename, and so on makes this a very valuable utility.
Finally, I'd like mention something else I have written: Ken Silverman's Rubix. Ken wrote all the code for displaying cubes, making turns, animations, sounds, and so on. I, Ben Jos Walbeehm, wrote the solvers that are now integrated into Rubix. I wrote 3 different solvers from scratch. That means I did not borrow anyone's ideas. I developed everything on my own. Writing a (3x3x3) Rubik's Cube solver was something I had been wanting to do for more than 20 years. When I finally started on it, I found that I had a need for displaying the actual cube and the results of the turns my program made. Not wanting to spend a lot of time writing code to display the cube, I browsed the web and found Ken's Rubix program. I contacted Ken and since he was very interested in integrating my solver into Rubix, he sent me the source code for it. That made writing my solvers a lot easier and I kept sending Ken updates of my solvers and making suggestions to him to make Rubix even better.
Once I had finished the 3x3x3 solver, Rubix could solve 3x3x3 cubes as well as the trivial 1x1x1 cubes. I did not like that "hole" between the 1x1x1 and 3x3x3 and browsing the web a little taught me that the 2x2x2 could always be solved in at most 11 turns. It took me only 2 days to write an optimal 2x2x2 solver, one that uses brute force to find an optimal solution for any given situation in a fraction of a second.
Around 20 years ago, after having manually solved 4x4x4 and 5x5x5 cubes, I realised that I understood enough about the cube that I could solve cubes of any size. So when my 2x2x2 solver for Rubix was finished, I finally decided to put that knowledge into source code and so I wrote another solver for Rubix, one that can solve any NxNxN cube for N >= 4. So Rubix currently contains 3 different solvers written by me. In chronological order: (1) A "pretty good" 3x3x3 solver. (2) An optimal 2x2x2 solver. (3) A solver that solves any NxNxN cube for N >= 4. It can solve 4x4x4, 5x5x5, 10x10x10, 64x64x64, ... cubes. Although Rubix has an upper limit now of 256x256x256, this can be trivially increased. The only limit is the available memory. My code will work for any cube size, restricted only by the finite amount of memory available on the computer running it.
Since I receive well over one hundred spam emails every day, my own SpamKill program uses very aggressive settings. So unless you are on my "safe list" or follow the instructions I have given in DeflOpt.txt, I may never see your email. So read DeflOpt.txt and follow its instructions when contacting me. Even if it is not about DeflOpt. ;)
This is a list of links to sites that I find valuable. This list is not complete and I intend to add to it whenever I find the time and inclination. In alphabetical order:
A great song performed by a great friend of mine: Anders Svensson. I didn't write this song. Just a great traditional song performed in a great way by Anders. Ye Jacobites By Name.
If you feel you should be linked here as well, do not hesitate to contact me. I am sorry that I made contacting me a bit hard, but the amount of spam I receive every day has made that necessary.
Please, do not call me "Ben"; I hate to be called "Ben"; my first name is "Ben Jos". This also serves as a test to see if people actually read what I have written. Calling me "Ben Jos" is much more likely to get a reply from me.
Copyright © 2013 Ben Jos Walbeehm.
All rights reserved.