:
September 9, 2018 - permanent link
Today’s Mini vMac 36.01 is the first beta of the 36.xx branch. The Changes page lists differences from current stable 3.5.8 version. (The only change in the source code from the last Development snapshot is the version number.)
In other news, AutQuit7 is updated thanks to this report. It now uses launchUseMinimum in launchControlFlags, so that AutQuit7 can launch “app” even if the preferred memory size is greater than the largest unused block.
September 2, 2018 - permanent link
Today’s Development source snapshot has some assorted fixes in preparation for moving to beta.
Reconsidering a feedback about the control mode, I changed my mind and decided that variations of Mini vMac without the control mode should not be supported. The build system will now consider it an error if “-km” options result in no key mapping to the control mode.
While in that area, if the “control” key is not mapped to the control mode, but some other key is, the user interface strings are now adjusted.
Also, when using the “-km” options, it may not make sense for the K command of the control mode to toggle the emulated control key. There is a new option “-ekt <dst>” to choose which emulated key to toggle. The user interface strings are adjusted accordingly. When this option is not chosen, Mini vMac will pick an emulated key that is not mapped to any real key, instead of always the control key.
I have concluded that “Abnormal Situation” reports in the regular non debug versions of Mini vMac are not on the whole helpful, and so are now disabled by default. There is a new compile time option “-abr 1” to enable them.
I spent a few days tracking down a twice reported issue when compiling with Microsoft Visual Studio 2017. It worked fine with an older version of Studio 2017 that I had, but once I downloaded the latest version, I was able to reproduce the problem. Turning off optimization made the problem go away. This compiler provides a way to set optimization level per function, so I was able to narrow it down to single simple function, where it was generating an “shr” instruction when it should have been an “sar” instruction. I don’t see any way this is undefined C behavior, so it looks like a compiler bug. To maximize the chance of a correct compile, I have changed the Mini vMac build system to disable optimization for this compiler. (This compiler is not used for the versions of Mini vMac that I provide.)
Trying to using the Location and Time Zone options (-alc, -lcy, -lcx, -atz, -lcd, -lczs, -lcz) when emulating a Mac 128K, 512K, or 512Ke will now generate an error. These options are saved in the Extended Parameter RAM, which these machines don’t have.
August 26, 2018 - permanent link
Today’s Development source snapshot removes the length limit on the Control-P command to copy the variations options, and adds an option to disable code signing.
Previously, converting a string from a cross platform C string constant to a representation that can be placed on the host clipboard involved a fixed sized buffer. Now that part of the conversion is done in two passes, first to find the length of the result, and second to actually produce the result. (The fixed size was 512 bytes, so it would be unusual to have hit this limit. It would need quite a lot of variation options.)
While in this area, I added the “copy variation options” command to the list in the help screen (Control-H). It would be nice to have translations of this string, and also the string “Variation options copied”, to the other ten languages supported by Mini vMac 36.
Also while in this area, I noticed that in the help screen, the original intent appears to have been that the letters on the left would be surrounded by single quotes. But that displaying a single quote wasn’t implemented properly and showed up as space. After implementing displaying the single quote, I think it looks better without. However, I noticed that preceding the “-” there are two spaces, since one was supposed to be the single quote. Somehow I never noticed this before. I have changed that to a single space.
Recently code signing has been added to the Cocoa OS X version of Mini vMac. But it has disadvantages. Apple could choose to revoke the certificate any time, and Mini vMac would stop working. Also, since Mini vMac doesn’t use Apple’s time stamp server (because that would break reproducible builds), Mini vMac will probably stop working when the certificate expires, 5 years after being issued. (The plan is to renew the certificate every year, so that a compile of Mini vMac should work for at least 4 years.)
Some people may prefer to avoid these issues, so I have added an “-sgn 0” option to disable code signing. The disadvantage is that OS X will by default refuse to run it (as happens with Mini vMac 3.5). This new option can be used in the Advanced Variations Service.
August 19, 2018 - permanent link
Today’s Development source snapshot adds a Serbian translation contributed by SerbXenomorph. This translation uses the Latin alphabet. SerbXenomorph contributed the translation in the Cyrillic alphabet, which was converted to the Latin alphabet with multiple online conversion services, which all gave the same result. It would take much more work for Mini vMac to support the Cyrillic alphabet, in its private cross platform font. Maybe someday. (According to Wikipedia, “Serbian is practically the only European standard language whose speakers are fully functionally digraphic, using both Cyrillic and Latin alphabets.”)
Today’s snapshot also adds a new compile time option, “-sbx 1”, to enable Sandboxing in the Cocoa version for OS X. This is an Apple security mechanism, so that any bugs, or even maliciousness, in Mini vMac can only do limited harm. This option might be the default in a future version of Mini vMac. However, it does remove some capabilities. The single requested “entitlement” allows Mini vMac to read and write files that the user has selected, with the Open File dialog, or by dragging into the Mini vMac window or icon.
But Mini vMac’s ability to automatically find files by name in special locations is severely restricted. It is prevented from finding “vMac.ROM”, “disk1.dsk”, “disk2.dsk”, etc. in the folder containing the application. It can find such files in a “mnvm_dat” folder created inside the application, but only read only. It does not have access to “~/Library/Preferences” to find “vMac.ROM” (but it does get access to the corresponding folder inside its container folder, which is obscure). It does have read only acces to “/Library/Application Support/”. Furthermore, if these named files are links that won’t work unless the file linked to is in one of the few places that a Sandboxed application has access to.
The Cocoa version for OS X now looks for the ROM image in one additional place, “/Library/Application Support/Gryphel/mnvm_rom/”, which can be read by a Sandboxed application.
August 12, 2018 - permanent link
I’ve changed my mind, and will trying using Apple’s code signing for the Macintosh OS X port, for 64 bits. This is implemented in the Mini vMac 36 Alpha Variations Service as of today. This allows Mini vMac to run on OS X without having to bypass Apple’s GateKeeper feature.
Hopefully, what I’ve implemented will work without causing too many problems. Normally signing an application involves requesting a signed time stamp from an Apple server. This is impractical for the Variations Service. And another problem is the result of this depends on the current time, which breaks the build process of compiling twice and checking for an exact match.
But it turns out to be possible to instruct the code signing tool to not do the time stamp. One possible consequence is that the application may stop working when the signing certificate expires in 5 years, since the application doesn’t have a signed time stamp to prove it was compiled before that. If I get a new signing certificate from Apple every year, this may not be too much of a problem.
------
Thanks to Scott Rickard, Anonymous, Trevor Glahn, Leonid, Chris Hanson, and Henry Shawcross for sponsoring one month of web hosting for the Gryphel project and over 4 days of health insurance.
August 5, 2018 - permanent link
The latest Mini vMac Development source snapshot fixes support for all supported IDEs in the new configuration tool. The new tool always uses the equivalent of “-cfg 1 -no-src 1” in the old build system, but these options were previously only implemented for “-e mvc”.
Also, Apple Xcode 9.4.1 is now supported.
And also, a memory leak is fixed in the Cocoa port for OS X, when exporting the clipboard. This was found by the Xcode Analyze feature.
July 29, 2018 - permanent link
The latest Mini vMac Development source snapshot adds a new way of finding the ROM image.
It was pointed out to me that using undocumented calls is not a good idea, so I have disabled the new code for working around the silly Path Randomization misfeature of OS X, which prevents finding the ROM image in the folder containing Mini vMac.
Instead, on all platforms (not just OS X), if the ROM image is not found in any of the locations that Mini vMac looks, the error can now be recovered from. You can drag the ROM image onto Mini vMac, and booting will resume. (Any of the methods that would normally mount a disk image will work to get the ROM, such as the Open dialog.)
July 22, 2018 - permanent link
Using the new (old) configuration tool, and some other techniques, the Mini vMac 36 Alpha Variations Service and corresponding Advanced Variations Service now only takes around 5 seconds for the preliminary result, down from 10 last week. Instead of generating a temporary page when the request is made, the cgi script waits for the preliminary result to become available.
The latest Mini vMac Development source snapshot merges in some fixes to the configuration tool from Ryan.
July 15, 2018 - permanent link
The latest Mini vMac Development source snapshot tries out backtracking a bit in the build system. Instead of a 68k Macintosh program to generate files to compile, it uses a cross platform standard C command line tool to generate a script to write configuration files, as was done prior to Mini vMac 3 over a decade ago.
This should allow the Variations Service to be more efficient, and is also more convenient for experienced programmers. The trade off is in making it harder for others to compile their own variations. Now I would prefer for people to use the Variations Service, and this is not only because of the funding model. Helping beginners figure out how to compile does not scale. And trying to making Mini vMac work well with random versions of random compilers also does not scale. With the Variations Service I can ensure quality of the compiled variations. The Variations Service has greatly improved in past months, fully automatic with 30 second turnaround (and still getting faster).
The source snapshot is now a standard compressed archive, in “.tgz” format. The source for the configuration tool is in “setup”folder. In a unix like system it can be compiled using something like “gcc setup/tool.c -o setup_t”, then run with something like “./setup_t -t mc64 > setup.sh”, and the output run with “. ./setup.sh”, and then Mini vMac can be compiled with “make”.
The new configuration tool is still a work in progress. It should be better documented when it is more settled.
The latest Mini vMac Development source snapshot merges in a number of fixes from Ryan.
The “-min-extn” option wasn’t working after the addition of the ‘P’ command of the Control Mode (for getting the compile time options).
The source image is now larger so that “-all-src 1” can work.
In the Cocoa version for OS X, the key NSHighResolutionCapable has been added to the Info.plist file, so that the Mini vMac window frame will draw in higher resolution on a Retina screen.
There is a new compile time option, “-gse 1”, for the Cocoa version for OS X, which on computers with more than one GPU allows the operating system to change which one is used. Otherwise on a MacBook pro, it is reported that the higher power discrete GPU is always used instead of the lower power integrated GPU, and that besides wasting power for no noticable benefit, it also takes time to switch on the discrete GPU when Mini vMac starts. update : I seem to have missed part of this patch. This will be fixed next snapshot.
“-gse 1” should probably become the default in the future. But I don’t have a MacBook pro to test it on, and I have a few questions about it.
A bug is fixed in the new “-svd 0” option, where in the Cocoa version in OS X 10.6 and prior, the “out” folder would not be created, if didn’t already exist.
“www.gryphel.com” is now HTTPS only, following current recommendation. Access to unencrypted HTTP is permanently redirected to the encrypted page.
If you want to access this website with very old web browsers, there is now http://www.gryphel.org, which has the same content, hosted by the same web server, but it works with unencrypted HTTP.
Due to travel, there won’t be a new development source snapshot until next week. Ryan has contributed a number of fixes.
June 24, 2018 - permanent link
The gryphel.com domain now points to new server. It may take up to a few days for this change to propagate across the entire internet. (If your DNS hasn’t updated yet, you will still get the old server.)
The new server and old server are currently identical for gryphel.com, except that the new server supports HTTPS encryption, i.e. https://www.gryphel.com.
In a few days, when the older server is no longer being used, and if everything looks good, any access to an unencrypted page like http://www.gryphel.com will be permanently redirected to the encrypted page. So if you notice problems with the encrypted pages, let me know now.
For very old web browsers that don’t support modern HTTPS, there is now http://www.gryphel.org. It is handled by the same new server, but this domain will not be redirected to HTTPS.
June 17, 2018 - permanent link
I’ve decided it is time for this website to support HTTPS (encryption), mostly to make Google search and web browsers happy. Rather than making the changes on the current web server and hoping it all works, I set up a new web server with up to date software, and if all works well, will switch the gryphel.com domain to it.
Current recommendation is to force browsers to use HTTPS, and even for HTTPS not support some of the older versions. But this website is intended to work with the oldest web browsers. To satisfy both, this website will be available on two different domains: “gryphel.com” will use HTTPS, and “gryphel.org” is for HTTP.
http://www.gryphel.org currently works for static content. (Supporting the Variations Service and the feedback form is yet to come.) https://www.gryphel.online is the current location of the HTTPS version. When everything is working properly, gryphel.com will be changed to work as gryphel.online does, and gryphel.online will probably be removed. (‘gryphel.online” is a free sample domain from my registrar.)
While there are two web servers, any changes to this site have to be made on both of them. So hopefully this transition period will be short.
If you notice problems with the new web server, let me know. At my location, the HTTP version seems at least as fast as the old web server, and HTTPS is less than twice as slow. HTTPS takes more round trips to the server to set up, so may be even slower from locations further from eastern US.
I considered supporting HTTP/2, which speeds up modern websites that access lots of different resources, but for this minimalist website, it seems more likely to just add a bit more overhead, and possibly compatibility issues. I also considered IPv6, which seems simple to support on the web server, but neither of the two internet connections I have available support it, so I can’t support it.
June 10, 2018 - permanent link
Today’s Mini vMac Development source snapshot fixes a reported bug where the Control Mode didn’t work on ports other than OS X. This was broken when the “-km” option was added.
Also, I’ve put in a work around for the Path Randomization misfeature added in macOS Sierra (10.12). If an application that Apple thinks is trustworthy is bundled together with malicious library code in the same folder, the malicious code may be run by the application. The silly way that Apple has chosen to prevent this is to in effect move the application somewhere else before running it, so it can’t find the library code. It can’t find anything else in the application’s folder either, which is a problem for Mini vMac, which looks for things in its folder, such as the ROM image file. So now the Cocoa port of Mini vMac will try to find the original location of the application, and use that instead of the location it is running from, when looking for the ROM image and other things. (Mini vMac doesn’t look for external library code, so Path Randomization has no benefit.) This is done using some undocumented SecTranslocate calls as suggested by “Objective-See” and Jeff Johnson. Previously, I have recommended using “xattr -rc <path to Mini vMac>” from the command line to disable Path Randomization. This will no longer be needed for Mini vMac 36.
This week I’ve tried to make the Variations Service automatically recover from the sort of network failure that happens every few weeks or so (or sometimes two days in a row). Previously the service would stop working until I noticed and fixed it manually.
I’ve also tried to make the Gryphel web server a bit more robust in some situations.
Today’s Mini vMac Development source snapshot adds the new build system options “-alc, -lcy, and -lcx” to allow manually setting the location fields in the Parameter RAM, and the options “-atz, -lcd, -lczs, and -lcz” to allow manually setting the time zone fields.
The “GetPRAM” tool has been updated to support these location and time zone options.
These Parameter RAM fields are not much used. Two example programs that can use the location fields are MacAstro and Star Atlas.
The Mini vMac 36 Alpha Variations Service and corresponding Advanced Variations Service now only take 10 seconds for the preliminary result, down from 15 last week. (And 20 seconds total, down from 30.)
This was made possible in part by a new compile time option in today’s Mini vMac Development source snapshot. “-svd 0” disables the save dialog for OS X and Windows when exporting a file (as used by the Mini vMac extra ExportFl and other tools). Instead the exported file is saved in a folder named “out” without a dialog, as was previously done in the Linux version. This makes it easier to run Mini vMac in an automated script and get results out.
Another change is that when the recently added “-ef 1” option is used to save errors to a file, the error file will be exported to the real computer, rather than staying in the emulated computer as before. (Unless “-nex” is also used.)
There is also another new option “-no-src 1” to only generate the configuration files and not save the source files. When the options “-cfg 1” and “-all-src 1” are used together, the generated source folder is identical for all variations. So it could save time to not generate it. But it doesn’t seem to be a significant amount of time, so the variation servce is not yet using the “-no-src” option.
Some additional speed was gained in the Alpha Variations Service by using ssh multiplexing.
There are changes to the Mini vMac 36 Alpha Variations Service and corresponding Advanced Variations Service. Instead of compiling the requested variation twice, verifying they match, and then presenting the result, it will now compile once, present a preliminary result, and then compile again, verify, and present a final result.
So it now only takes 15 seconds instead of 30 to get to the point of downloading your variation (and you can verify the checksum and signature). Before actually running the variation, you should wait for the download page to update with the final result, which should only take another 15 seconds.
Another change is that the Alpha Variation Service is now reproducible. That is, if you ask for the same options twice, you will get the exact same application archive. (The file name will be different, but the contents are the same.) Previously different variation requests would get applications with different names, like “mvm10280” and “mvm10281”, which made the resulting archives different, even though the compile process was otherwise reproducible. Now all variations get the same name “minivmac”, and the application archives are renamed to something unique as a final step. The Sponsor Code used does not effect the resulting Variation, so two sponsors requesting the same variation will get the same result. (With no Sponsor Code, a demo is created, which is different from the sponsored variation.)
Today’s Mini vMac Development source snapshot has a fix to allow the Alpha Variations Service to report errors correctly. The simplest way to fix it was to remove the option of using “;” to allow multiple variations in one run. The new Alpha Variations Service no longer uses this, it always processes one variation at a time, and never in larger batches. (Larger batches would not work properly since all variations now all have the same name.)
Another change is that the build system now will report the name of an unrecognized option in the error message, not just hilighting it, to allow the Advanced Variations Service to work better.
------
Thanks to Herb Mann, Sam Coupe, Michael Cremer, Callum Fraser, Roland Zimmerman, Ian Dunbar, Chris Hanson, and Henry Shawcross for sponsoring one month of web hosting for the Gryphel project and over 6 days of health insurance.
Today’s Mini vMac Development source snapshot adds a new build system option “-km <src> <dst>”, for changing the mapping between keys on the real Keyboard and keys on the emulated Keyboard, or the Mini vMac Control Mode.
April 29, 2018 - permanent link
Today’s Mini vMac Development source snapshot adds the new build system options “-hcr, -hcg, and -hcb”, to select the initial value of red, green, and blue components of the highlight color in the Parameter RAM. This was requested by Karl.
The new “GetPRAM” tool can be used to get the numeric values these options require. It gets Parameter RAM settings in a format that can be used with the the Mini vMac build system or the new Advanced Variations Service. So you first use the Macintosh Control Panels to select the desired settings, then launch GetPRAM.
Also in today’s snapshot, the error message generated by the build system always include the name of the option which had the problem, making error messages from the Advanced Variations Service more useful. (If you use the build system application directly, not telling it to save error messages to a file and quit, it would usually highlight the text of where the problem was.)
April 22, 2018 - permanent link
There is now an Advanced Variations Service for Mini vMac 36 Alpha, where options are entered as text, instead of the long list of controls in the regular Variations Service that is getting unwieldy as more and more options are added. (The plan is to remove all but the most popular options from the regular Variations Service and call it the Basic Variations Service.)
The Advanced Variations Service is actually easier to use than the regular Variations Service when you want something mostly like a variation you already have, because of the new ‘P’ command of the Mini vMac Control Mode to get the options of an existing variation.
April 15, 2018 - permanent link
Today’s Mini vMac Development source snapshot adds a number of features to the build system. The motivation is that the Variations Service page gets unwieldy as more and more options are added. So I’m thinking of instead having a Basic Variations Service, which only has the most popular options, and a new Advanced Variations Service, which allows pasting in options as text. (With the new ‘P’ command of the Mini vMac Control Mode to get the options of an existing variation, you would be able to easily update a variation.)
If the new option “@” is used, no developer options are permitted to the right of it. This will allow the Variations Service to allow the user to specify options as text without the chance of breaking the service. (For example, the ‘-e’ option to select the the development environment would not work well.)
The new option “-ef 1” causes the build system to write error messages to a text file, instead of displaying an alert dialog. This will allow the Variations Service to allow the user to specify options as text, and get any error messages, such as about bad syntax, back to the web page shown to the user, rather than breaking the service.
If the new option “!” is used, options to the right of it will override options to the left of it. Normally it would be an error for the same option to be used twice. It is still an error for an option to be used twice on the same side of ‘!’.
The new option “-cte 1” causes the build system to generate source code that causes the compiler to generate an error. This is for testing the variation service.
If the new option “-bte” is used, the build system will treat it as an error. This is for testing the variation service.
April 8, 2018 - permanent link
WordMaker 1.0.4, a word processor, has been added to the software hosted by the Gryphel Project. Josef of Team Amiga Source Code Preservation notified me that they had obtained the source code and permission to GPL it, among a batch of other software, mostly for Amiga, originally from New Horizons Software, Inc.
April 1, 2018 - permanent link
Today’s Mini vMac Development source snapshot adds a new ‘P’ command to the Mini vMac Control Mode, which copies to the clipboard (of the real computer, not the emulated computer) a string containing the options describing this variation of Mini vMac.
The string generated by the ‘P’ command starts with a new option, “-br”, which is for future use and currently has no effect. It tells the build system that the requested options were from a specific branch (version) of Mini vMac. So “-br 36” means from branch 36. If the default settings have changed from since that older version, then the build system will use defaults of the old version, rather than the current defaults. So if you use the ‘P’ command on some variation of the current alpha version of Mini vMac, and pass it to the build system of some future version, the newly generated variation will behave as close as possible to the earlier variation.
There are three new build options that may have different defaults in some future version: “-eci”, “-ecr”, and “-eck”. They can be used to disable the ‘I’, ‘R’, and ‘K’ commands of the Mini vMac control mode, which are use to operate the emulated Interrupt Button, emulated Reset Button, and emulated Control Key. In the future they may be disabled by default. In the original Macintosh, the Interrupt and Reset buttons were disabled by default. You needed to install the “Programmer’s Switch” to use them. The original Macintosh did not have a control key. And, using the ‘K’ command accidently would be confusing.
March 25, 2018 - permanent link
Today’s Mini vMac Development source snapshot adds a new build option “-iid 1” to enable a new “Insert Ith Disk Image” feature. When this feature is enabled, if the Control key is held down and a number key from ‘1’ to ‘9’ is pressed, then Mini vMac will try to mount a disk image named from "disk1.dsk" to "disk9.dsk" in the folder containing the application.
This is the same series of disk image names that are automatically mounted when Mini vMac is launched. But it stops at the first image not found. So if you leave a name unused, then you can use a control-number key to mount disks after launch. Or, you can use a control-number key to remount a disk that was automatically mounted at launch and then later ejected.
One example use is if you have one copy of Mini vMac running a development environment (such as MPW) that is used to compile a program to a disk image. The disk image is then unmounted and mounted on another copy of Mini vMac running a testing environment. If the compiled program crashes badly, the development environment is not disturbed. The control-number key feature makes it easier to move the disk image back and forth between the two copies of Mini vMac.
Also, the version numbering scheme has changed as of this snapshot. Instead of “3.6.0”, it is “36.00”. The distinction between major and minor version numbers has not been useful. Instead there is now a single branch number. This allows more bug fix releases (up to 99 instead of up to 9) without taking more space in the version string.
And also with this snapshot, the Mini vMac Alpha Variations Service and the Alpha Changes list are back.
March 18, 2018 - permanent link
SigCheck, SigWrite, and MakeKeys have been updated and renamed to PSgCheck, PSgWrite and PMakKeys. They are being replaced by a similar set of tools, with the same names, that use a different format for keys and signatures (instead of formats that are sort of but not quite compatible with MacPGP): SigCheck, SigWrite and MakeKeys.
March 11, 2018 - permanent link
Today’s Mini vMac Development source snapshot fixes a bug in emulating the trace flag of the CPU. (Thanks to Tara Keeling for causing its discovery.) It seems that in months of testing of Mini vMac 3.5, I never used Macsbug. Stepping through code (with Command-S or Command-T) doesn’t work properly. An optimization to the main cpu emulation loop isn’t valid when the trace flag gets set. I found a way to fix it which doesn’t change the optimized main loop, but just the code before and after. But it can change the timing of other kinds of interrupts by one instruction, potentially causing subtle differences in behavior anywhere. So I don’t plan to put this fix in stable Mini vMac 3.5, it needs more extensive testing.
I’ve added a blinking busy indicator to the status bar in GSgWrite. This is partly to reassure the user that it is working, but mostly it is to tell the AutoSlow feature of Mini vMac that it is working. So that documentation doesn’t need to say to turn off AutoSlow. (Other tools will be updated later to include this code.)
On further consideration, I’ve decided to backtrack and say that GSgWrite, SigCheck, SigWrite, and MakeKeys are still in Alpha, not in Beta, because of not being satisfied with the format for public and secret keys. They are currently using a format that is sort of compatible with PGP, but not actually what PGP would ever produce. For multiple reasons, I’m thinking it would be better to define a GRY format for keys, and then have one set of tools that only deal with GRY format keys (and work with GRY format signatures), and also have another set that uses the PGP semi compatible format that is currently used (and work only with PGP format signatures). I have defined the GRY keys format, and have code that implements them. Tools using this code will come soon.
------
Thanks to Chris Hanson, Steven Stepanek, Hendrik Cyrus, Mike Keller, Jeremy W Karpenske, Joseph Oswald, and Arnaud Abbati for sponsoring about one month of web hosting for the Gryphel project and over 4 days of health insurance.
March 4, 2018 - permanent link
SigCheck, SigWrite, GSgWrite, and MakeKeys are updated again, to fix an issue with the keyboard shortcut for the Host Copy command not working in System 6 and before. They have also been made generally more robust in System 6 and earlier, in protecting against desk accessories doing odd things. Also, they now work on a Mac 128K.
MakeRand has been updated to use the current editing code used in the other tools.
And finally, in today’s Mini vMac Development source snapshot, the build system is updated to use the same current editing window code. This includes the Cut/Copy/Paste commands that use the Host Clipboard, a working Undo command, and some other improvements.
February 25, 2018 - permanent link
There are new versions of SigCheck, SigWrite, GSgWrite, and MakeKeys, which are now declared to be in Beta (instead of Alpha).
The error reporting is a bit better, aborting with command-period can now work, and the user interface is now generally responsive when the programs are busy.
If you are checking a lot of signed messages with the same public key, you can put the key in a file named "pub_key.txt" in the same folder as the SigCheck application, and it will use that instead of asking for it.
Similarly, if you sign a lot of messages with the same secret key, you put the key in a file named "sec_key.txt" in the same folder as the SigWrite or GSgWrite applications, and it will use that instead of asking for it.
February 18, 2018 - permanent link
GSgWrite is a new tool for writing digital signatures that is very similar to SigWrite, except that it uses a different signature format. SigCheck has been updated to handle this new format. (Also SigWrite has been updated to include recent improvements in the text editing window code from SigCheck.)
The main difference in GSgWrite from SigWrite is that when a message containing a public key, or even a nested signed message, is signed with GSgWrite, the signed message contains the exact same text without modification. The PGP format created by SigWrite is designed to be read in one pass from beginning to end, so some kinds of text could cause confusion and have to be modified. The “GRY” format created by GSgWrite is designed to be scanned backwards from the end to find the end of the message body.
This makes the GRY format incompatible with the PGP format. And since it is incompatible anyway, some further changes were made.
First, the GRY format is a bit more compact. For a 1024 bit key, the body of the GRY signature is always exactly 3 lines of 64 characters each. Second, the GRY format format attempts to mitigate known weaknesses in the md5 checksum by including a second md5 checksum, of the same data with the bytes in reverse order. Even if someone finds a practical way to generate a file with a given md5 checksum, finding a file that also has the second checksum right is likely to be more difficult. (The size of the signature depends on the size of the key, not on the size of the digest. A larger digest is fine as long as it is smaller than the key.) Also, CRC-24 checksums for both orders are included in the digest, since code for CRC-24 is already there (used for protecting the signature body against accidental corruption).
February 11, 2018 - permanent link
Today’s SigCheck 0.4.0 now has a working Undo command, since I was in the area of the editing code. Again, this will later be added to all the other Mini vMac extras which share this code for an editing window.
Also in this version, it finds the end of the message that is signed by scanning backwards from the end of the text. Which would allow most anything to be in the signed message without modification, such as a public key or a nested signed message. But this would be incompatible with MacPGP, so I will define another signed message format to allow this, in the near future.
------
Thanks to Justin Williams, Rienk Koolstra, Marcin Rusinowski, Leo E Tognella, Jonathan Heiman, and Grafico Freelancer for sponsoring about one month of web hosting for the Gryphel project and 6 days of health insurance.
February 4, 2018 - permanent link
Today’s SigCheck 0.3.0, when run in Mini vMac, adds commands to the Edit menu that operate with the clipboard of the real computer instead of the emulated Mac. They have keyboard shortcuts that use the Option key. So Command-Option-V will paste the clipboard of the real computer into SigCheck. This simplifies using SigCheck, as ClipIn is not needed.
This feature will later be added to the other digital signature tools, and also the Mini vMac build system, and also other Mini vMac extras, which all share code for an editing window.
January 28, 2018 - permanent link
The Mini vMac Variations Service now signs the md5 checksum and other information for generated variations. (Automated signing was the reason for the lengthy excursion into digital signatures.)
The Variations Service has its own new signing key, with its own new page: Gryphel Key 2. There is also a new page for the main Gryphel Project Key, at Gryphel Key 1. This page also has links to copies of key placed elsewhere on the web, to help verify that it is correct.
January 21, 2018 - permanent link
MakeRand is a new tool for making random hexadecimal data, to be used with MakeKeys. So the digital signature tools (also including SigWrite) should now be usable. (SigCheck was already usable, for checking signed messages found on this website.) But these tools are still under development.
January 14, 2018 - permanent link
SigWrite is a new tool for writing digital signatures that can be verified with SigCheck (which has been updated). MakeKeys is a new tool for making secret and public keys to be used with SigWrite and SigCheck. These tools are regular Macintosh applications, unlike last week’s MPW tools to do the same thing. These tools are still under development and may have different behavior when finished.
One missing piece is a tool to generate truly random hex data to be used as input to MakeKeys. I'll adapt more code from MacPGP, which looks at the timing of key presses, to make such a tool soon.
January 7, 2018 - permanent link
There are new versions of SigWrtTl and MkKeysTl, two MPW tools which are still under development. The source code is being cleaned up to match previous work on SigCheck and SigChkTl, which in the process has served as code review, finding a number of things to fix.
December 31, 2017 - permanent link
SigWrtTl and MkKeysTl are two new MPW tools. They are still under development. Regular Macintosh applications to do the same thing should follow. SigWrtTl writes digital signatures that can be verified with SigCheck, SigChkTl, or MacPGP. MkKeysTl makes secret and public keys to be used with SigWrtTl and the verifying tools.
Also to come is a tool for making a file a random bytes for using with MkKeysTl. I decided to split random byte generation from MkKeysTl so as to make MkKeysTl much easier to test.
December 24, 2017 - permanent link
Last week’s SigCheck alpha is only the first of a planned trio. The second is a tool to sign a message, and the third to create a private/public key pair. Hopefully the next two should go faster from already being familiar with the MacPGP source. Also, as I remove unneeded code from MacPGP, I’m leaving code for both signing and key generation in as long as possible, rather than going through this process from scratch three times.
SigCheck can’t be finished until the other two utilities are done, because in some circumstances I want to use a slightly different format for signed messages than MacPGP does. In particular, when the signed message contains a public key. MacPGP allows reading several signed messages in a single file, and it reads the file linearly, so to reliably find the end of a signed message, some sequences of characters are not allowed in the body. So a public key gets modified a bit. SigCheck assumes there is only a single signed message, and could be changed to scan backwards from the end, so anything can be allowed in the body, such as an unmodified public key. For a balance of simplicity and compatibility, I think my signing tool will usually write MacPGP format, but if that would require modifying the body, it would use a different format, so the body remains unmodified.
December 17, 2017 - permanent link
SigCheck is a new tool for checking the signed checksums on this website. It is still under development, but seems to work. (It is regular Macintosh application, unlike last week’s SigChkTl MPW tool.)
December 10, 2017 - permanent link
SigChkTl is a new command line tool for Macintosh Programmer’s Workshop for checking the signed checksums on this website. It is still under development. A regular Macintosh application to do the same thing should follow.