www.gryphel.com/c/mail/v12 - feedback

Gryphel Project Mail

Volume 12

To send mail to me, use the feedback form.

( - latest - )

permanent link

Sent: Mon Jan 18 23:07:11 2021


I'm on macOS 10.14, and I've downloaded both the Mini vMac and Mini vMac 26, and executed the command you provided to ensure the apps each have access to their ROM file and others.

However when I open the app (in both cases) i'm greeted with the message "I can not find the ROM image file "vMac.ROM" [or "MacII.ROM"]"." Have I missed a step? the apps were both downloaded into my Downloads folder, could that cause this problem?

Thanks for your time!

status : information needed

Thanks for bug report. Some things to check, for the Macintosh Plus emulation:

Is the ROM image file named exactly “vMac.ROM”, and located in the folder containing the application (the Downloads folder in this case)?

Is the downloaded archive named “minivmac-36.04-mc64.bin.tgz” and from the 36.04 (Stable) Standard Variations page?

The “xattr” command can also print out extended attributes, by leaving off the “c” argument. If you expand “minivmac-36.04-mc64.bin.tgz” again, and execute “xattr -r <path_to_application>”, you should see a bunch of lines ending in “com.apple.quarantine”. Then run “xattr -cr <path_to_application>”, which is supposed to clear these extended attributes. To verify, run “xattr -r <path_to_application>” again, and no lines should be printed.

Does dragging and dropping the ROM image onto the Mini vMac application window work?

Does it make any difference to move Mini vMac and the ROM image to some other folder than the Downloads folder?

Does it help to move the “vMac.ROM” file to one of the other locations Mini vMac looks for a ROM image?

Does the 32 bit version (“minivmac-36.04-imch.bin.tgz”) behave any differently?

permanent link

Sent: Fri Jan 1 18:57:03 2021


is there any way to work with "full" harddisk images, that I could `dd` onto physical media and use in a (hardware) 68k Mac?

The images I’m using successfully with mini vMac to boot it, won’t boot a real Mac SE. Looking at what "file" says about it, it’s a completely different partition map.

Thanks for replying to my last question regarding Mac II & LocalTalk emulation, it helped!



status : responded

The replacement floppy disk driver of Mini vMac can not handle a full hard disk image. It probably can handle an image of a partition of a hard disk. The dd command can be used to read and write a partition.

permanent link

Sent: Wed Dec 23 20:03:39 2020

Hey, I've been using the mini vMac Tool now for several years and I have to say it is definitely one of the best mac emulation options, it has been really helpful when copying files over to real macs, testing software, and several other things. Keep up the good work!

status : received


permanent link

Sent: Thu Dec 17 04:29:20 2020

When I try to launch Mini vMac (minivmac-36.04-mc64.bin.tgz, which appears to be the latest stable release) on my new iMac running Catalina (10.15.7), I get an error message ("The application 'Mini vMac' can’t be opened.") That is the entire extent of the message. There is no more, just an "OK" button. If I right-click or control-click on Mini vMac and select "Open" (such as to enable launching an application that is not registered with Apple), I get the same error message.

As I understand, the 37.01 beta is for macOS 11.0 or later, which I do not currently have.

I tried xattr -cr /Users/George/Desktop/Mini\ vMac/Mini\ vMac.app, but that made no difference.

You asked what is my allowed apps setting in System Preferences, Security & Privacy, General. The answer is "App Store and identified developers." The other choice ("App Store") is not selected.

As noted, I can successfully launch Mini vMac (minivmac-36.04-imch.bin.tgz) on my MacBook Pro running High Sierra (10.13.6).

'Any ideas?



[previous message]

status : information needed

A search on the web suggests this error message can happen if the permission flags are incorrect of a file inside the application, and it can be fixed with the chmod command. (And another page.)

How did you unpack the minivmac-36.04 archive? If it isn’t what you did, you could try right clicking on the icon and select Open With > Archive Utility.

By the way, the 37.01 beta should work in all versions of macOS.

permanent link

Sent: Thu Dec 17 01:24:37 2020


I’m building v37.01 with XCode 12.3 on M1. The result is a working binary, that runs my System6 systems just fine. But as soon as I try to boot a System 7.0 disk (which used to work fine on my Intel Mac before), I either get "division by zero" in the early boot up phase, or "system is damaged. Use 'Installer' to refresh".

My config is :

./setup_t -t mcar -m II -hres 512 -vres 342 -magnify 1 -drives 12 -mem 8M -mnb 1 -kyt 4 -svl 3 -lt -lto udp -e xcd -ev 12300 -n "minivmac-macii-smallscreen-m1"

Any hint is appreciated.



status : open bug report

The issue is with LocalTalk emulation for Macintosh II (“-m II -lt”). This issue was also in prior versions of Mini vMac, it is just more obvious in Mini vMac 37 now that the “-lt” option enables the AppleTalk setting in PRAM (because a bug fix allows AppleTalk to work properly when turned on at boot). If you are not actually using AppleTalk, the easiest fix is to remove the “-lt” option.

As for actually fixing the issue ... Regressions in emulation, things that used to work and now don’t, can always be fixed. For things that never worked, there is no straightforward path to a fix.

permanent link

Sent: Wed Dec 16 15:41:47 2020

Hi Paul,

I'm quite used to compiling software on Linux and I was able to build minivmac v37 beta on Ubuntu with no issues. I did that first before attempting to tackle a build on my MacBook (x86_64, Big Sur 11.1, XCode 12.3 with commmand line tools installed). Building the latest v37 beta using XCode I get a working binary, but with no sound (not even the boot chime), even when I force enable it. I've tried 8bit and 16bit sampling to no avail. Here's my method:

clang setup/tool.c -o setup_t
chmod +x setup_t
./setup_t -t mc64 -e xcd -ev 12300 -cl -m II -hres 704 -vres 450 -depth 3 -fullscreen 1 -magnify 1 > setup.sh
chmod +x setup.sh

I also tried adding:

-sound 1 -sss 4

I see the sound API overrides seem to be for Linux only, unless I'm missing something? The build guide suggests it should automatically target the correct sound API from the other information about the target.



Sent: Wed Dec 16 21:00:57 2020

Hi Paul,

Re: compilation issues for audio on XCode 12.3 - If I build as an XCode .proj project rather than via command line tools it also has no working audio. I see the following build error:

"This application, or a library it uses, is using the deprecated Component Manager for hosting Audio Components. This is not supported when rebuilding against the 11.00 or later SDK. Also, this makes the host incompatible with version 3 audio units. Please transition to the API's in AudioComponent.h."

Is the downloadable source code for 37beta up to date? I see that you've been building for Apple Silicon which seems to need the same version of XCode I am using, so I'm at a loss to explain why it wouldn't be working here.



status : fixed

Thanks for the bug report. Oops, my build for Apple Silicon doesn’t have sound either. That’s embarrassing to have not noticed. One excuse is that I have been mostly developing on an M1 Mac Mini through screen sharing, which does not transmit sound. I should have looked at the deprecation warnings more carefully. Well, the public Beta is for catching things like this.

The Cocoa port descends from SDL code. So the easiest way for me to fix this is probably to examine the code of lastest SDL version.

Yes, there is no sound API option for macOS.

update 12/20/2020 - The lastest SDL seems to have moved on to a different Macintosh sound API. But before that happened, Dominik Reichardt created a patch for SDL that can be adapted to Mini vMac. This is done in the new Mini vMac 37.02 beta.

permanent link

Sent: Wed Dec 16 03:35:15 2020

When I try to launch Mini vMac on my new iMac running Catalina (10.15.7), I get an error message ("The application 'Mini vMac' can’t be opened.") If I right-click or control-click on Mini vMac and select "Open" (such as to enable launching an application that is not registered with Apple), I get the same error message.

I tried xattr -cr /Users/George/Desktop/Mini\ vMac/Mini\ vMac.app, but that made no difference.

However, I can successfully launch Mini vMac on my MacBook Pro running High Sierra (10.13.6).

'Any ideas?



P.S. My ultimate goal is to get a copy of SonyTest 7.0 onto my Macintosh SE to help me diagnose a floppy drive problem. I think the floppy drive heads need alignment, but the drive might have another problem. (It is not as simple as the eject motor needing cleaning, lubrication or a replacement gear. All that has been done.) I do not have an alignment floppy, but I do have fairly serious electronic diagnostic equipment (o'scope, etc.) Any hints on diagnosing problems with 800K floppy drives, schematics, etc. would be welcome, too.

status : information needed

First, which Mini vMac version did you download? Is it “minivmac-37.01-mc64.bin.tar”?

Second, is that the entire error message? Or does it continue with something like “because Apple cannot check it for malicious software.” Or anything else?

Third, what is your allowed apps setting in System Preferences, Security & Privacy, General?

It sounds like you know much more about floppy drive hardware than I do. Mini vMac currently doesn’t actually emulate this hardware, but replaces the driver for it in the ROM. (Mini vMac emulates most of the rest of Macintosh Plus hardware.)

update - follow-up message

permanent link

Sent: Mon Dec 14 15:53:25 2020

Is it possible to build a customization for the Mac SE/30 (either with the standard ROM or the BMOW MacRominator II), or does its 68030 processor preclude this? I'm having difficulty using Mini vMac to create disk images with systems that are bootable on the SE/30, which I suspect is due to the fact that the installer thinks its a Mac mini.

status : responded

Mini vMac can not yet emulate a Mac SE/30. The ROM from an SE/30 should work in the Macintosh II emulation of Mini vMac, but that hybrid is not an SE/30 and would not be compatible with all the same software.

The SE/30 is said to support System 6.0.3 to 7.5.5, so if you run the installer for one of these versions, and ask it to install System software for any Macintosh, the result ought to run on SE/30 in addition to the computers that Mini vMac can emulate.

That is for an original SE/30. People have done modifications, like replacing the ROM with a later 32 bit clean one. Which would change the system software versions that would work.

(By “Mac mini”, I would guess you mean what other people call a Compact Macintosh, and not the much much later Macintosh model introduced in 2005.)

permanent link

Sent: (via email) Mon, 14 Dec 2020 04:02:25


I wanted to try the variations service to build myself an executable for Mac OS 9, but it seems that option was removed. I distinctly remember it being there a few years ago. Of course I downloaded the source, created a compile VM, it spat out the files for MPV, I dug up my memories on how to compile it (on real OS 9) and.. it was so buggy it froze right after boot. Then I tried playing with the parameters and using different system images (6.0.8, 7.1, 7.6.1), but to no avail.

Is it possible to produce an executable for me for said platform (MacII, sound, 800x600x256)? Or was that host platform abandoned for a reason, e.g. not enough interest, difficulty in fixing bugs etc.? I mostly just want to play Hellcats Over the Pacific on OS 9.2.2 but the last version it works on without a black screen is on is 9.0.4, so Mini vMac is my only hope. Sure, I know I might as well play it on my main machine but my OS 9 box has all my newer games so it would be really nice.

I will, of course, gladly pay for a variations subscription to support your work.

Best regards,
[... name ...]

status : received, work pending

Thanks for the bug report. Mini vMac 37 just entered Beta, so this a good time for me to test compiling for Mac OS 9. I have some memory that the very last MPW compilers were buggy, and it was necessary to use earlier ones. But that might have been for the 680x0 compile and not the PowerPC version used for Mac OS 9.

Unfortunately, I stopped producing official binaries for Mac OS 9 and earlier when I moved to using a set of cross compilers compiled from a single version of GCC. Using these cross compilers is very convenient, and allowed speeding up the Variations service from minutes to seconds. (The current form of the Variations service would not be viable if a compile could take minutes.) But I have decided this compiler set is too limited, and for Mini vMac 37 figured out how to get the same speed with multiple compilers on multiple platforms by throwing more hardware at the problem (especially memory). This made possible supporting the new Apple Silicon.

So now it is relatively easy to support any platform that has a C compiler that runs on some (possibly other) intel platform that has an SSH server and Bash. Which doesn’t directly help for supporting Mac OS 9 using MPW. One possibility is to try the Retro68 compiler again. I couldn’t get it to work some years back, but it looks like significant work has been done on it since. Another possibility is some enhancements to Mini vMac to allow better coordination with MPW running in emulation, along with some other tricks.

permanent link

Sent: (via email) Mon, 16 Nov 2020 11:33:05

Hey Paul,

Was wondering if you had any insight into this issue that I've posted about on the e-maculation forums:


Basically, I'm unable to get sound working on a Raspberry Pi4 with vMac compiled with SDL and ALSA. Other apps (including Basilisk II, for example) work with SDL and ALSA so my overall setup seems OK. Anyway, just wondered if you might have any pointers.

[... name ...]

status : documentation pending

To start with, “-snd-api alsa” would at best do nothing when used “-api sdl”. The code for using sdl is trying to be as platform independent as possible, and does not implement using alsa directly. The build system attempts to verify that any regular options used are valid, and any combination of them that doesn't work and the build system didn't catch is a bug. This is not true for developer options like “-snd-api alsa” and “-api sdl”, since often what is desired is to generate as close as possible to working when porting to a new platform. I should document this distinction.

I thought SDL provides its own options for choosing how sound is implemented. Also I would think alsa is normally the default for SDL on linux. But I don’t know about SDL for Raspberry Pi.

The SDL port is mostly there to provide a stepping stone for more native ports. Is there a reason you want to use it instead of the X11 port? If the SDL port is doing something better, I’d prefer to fix the more native port.

By the way, “-cpu arm” is not needed for your options, it is implied by “-t larm” (Linux on ARM).

permanent link

Sent: Fri Nov 6 03:27:14 2020

Hey it's me again, the guy who asked about the vsync and less accurate mouse emulation for tablets.

Sent you some $$ because this is continues to be the best software ever! THanks so much for doing what you do.

I seem to have a bug that I'm guessing is related to high-DPI display. I'm trying to compile a custom version, nothing fancy just one that runs in the BG by default. I'm getting a strange error where the graphics draw in the lower left 1/4 of the window.

I can email you a screenshot or something. No pressure or anything, would be happy to help figure it out in any way I can. I'm using the instructions as-is on the developer page.

I can be reached at [... email address ...]

thank you~


status : responded

If you have not already done so, try Mini vMac 37 Alpha. This sounds like a bug that was fixed: “When compiled with a recent version XCode, like 11.4.1, Mini vMac for OS X would not draw correctly on a retina display. It now calls "setWantsBestResolutionOpenGLSurface:NO" when available. A comment found in SDL 2.0.12 explains: "Note: as of the macOS 10.15 SDK, this defaults to YES instead of NO when the NSHighResolutionCapable boolean is set in Info.plist". This problem occurred because the NSHighResolutionCapable key was added in July 2018 to make the window frame look better on retina screens.”

permanent link

Sent: Tue Nov 3 15:44:58 2020


I sent you something yesterday about Temple of Apshai Trilogy not working under Mini vMac. I have an update to that. It will work, but only by running at the slowest emulation speed. Control-S-Z

Hopefully that helps. Thanks for all your efforts!!

status : responded

[previous message]

That’s good that you independently found the same work around.

permanent link

Sent: Tue Nov 3 01:07:43 2020

Hello there. I very much appreciate all your efforts with Mini vMac!!

Recently a playable (hacked) version of "Temple of Apshai Trilogy" was made available on Macintosh Garden. The game does start and plays the intro music but the emulator seems to have problems with sound during screen transitions. It will stick on the last note played when transitioning from the title screen to the menu and then will freeze the emulator when the next sound is to be played. (encounter in a dungeon)

This was also tested with Mini vMac alpha v37 to see if the fix for Winter Games would also apply to this issue. But alas, it does not not solve the problem.

status : responded

This game seems to work at 1x speed. The 8x default speed of Mini vMac is not compatible with all software. Making most software more usable is I think a worthwhile tradeoff.

The speed is controlled by the ‘S’ command of the Control Mode. If you use this a lot, there is also compile time option to start at 1x speed, “-speed z”.

permanent link

Sent: Mon Nov 2 14:42:32 2020

I got a problem my mini vmac screen won't work can you help me

status : responded

Sorry, not without more information.

If you have not already seen it, please see the Getting Started with Mini vMac instructions.

permanent link

Sent: Sun Apr 22 07:17:55 2018

Hi Paul,

Minor (?) bug report. If you run SimCity 2000 (I've tried 1.0 and 1.2) in Mac II mode and open the neighboring cities popup (button next to the big green dollar sign in the left-side toolbar) then it shows the populations of those cities with either ridiculously large population numbers or sensible numbers with many leading zeros. I always remember this working on my real Mac (when it still worked) and it seems to work okay in Basilisk II.

I'm guessing this has to do with the FPU emulation? Maybe this expected at this point? I seem to remember you mentioning somewhere that the Mac II emulation wasn't quite done... Anyway, thanks for your time!


status : open bug report, work pending

Thanks for the bug report. This has been reported before, but that it works in Basilisk II is new information. Which provides a straightforward, if very time consuming, path to fixing it.

permanent link

Sent: Mon Oct 19 05:55:43 2020

i have been having issues getting the ua608d utility to unarchive the system 6 os files using command prompt on windows 10

i keep getting

usage: unar archive_file dst_file

as a response or nothing at all

so i am pretty sure i am mostly trying to use it correctly but missing something small in the syntaxing

after using cd to navigate to the folder i am using i have tried just running the command supplied './ua608d SSW_6.0.8-1.4MB_Disk1of2.sea.bin "System Startup"'

but that errors as '.' is not a recognized internal/external command program or batch file

running 'ua608d.exe ./ua608d SSW_6.0.8-1.4MB_Disk1of2.sea.bin "System Startup"' gets me my error

and using 'start ua608d.exe ./ua608d SSW_6.0.8-1.4MB_Disk1of2.sea.bin "System Startup"'

to run the executable just runs it for an instant before it quits

and follow up or advice to correct this probably user error would be appreciated

if it would be easier to email me feel free to on [... email address ...]

status : received, definitive reply pending

I’ll need to try it on a Windows machine to be sure, but I’d suggest:

ua608d.exe SSW_6.0.8-1.4MB_Disk1of2.sea.bin "System Startup"

That is, get rid of the extra “./ua608d”.

In a unix style shell, “./ua608d“ will run an executable file named “ua608d“ located in the current directory. Just saying “ua608d“ will not find it in the current directory, it will instead look for it only in previously defined paths. If I remember correctly, this is to prevent unpleasantness if some joker has made an executable named such as “ls”. Apparently though, in the Windows shell it will look in the current directory.

permanent link

Sent: Sun Oct 18 18:22:50 2020


I have a small request for the next version of Mini vMac. I know the "v" icon that shows on the desktop for non-800k disks reflects the fact that you basically replaced the floppy driver with a custom virtual device that reads any size of disk image. While I would absolutely love it if Mini vMac eventually emulated a real hard drive I understand that it's not currently and might never be on your road map.

That's all great but I don't really want or need to be reminded that the underlying devices are non-authentic. So, if was hoping that you might introduce a new compile option--that would be entirely cosmetic--that would cause 1440kb (for HD floppy disks) to show the standard floppy disk icon and images of all other sizes to show the hard disk icon?

Thanks for considering my request.

status : possible feature pending

That would be a reasonable compile time preference. One complication I remember from the last time a similar request came up is that there does not seem to be a standard hard disk icon to be found in the System or Finder files, I suspect that various driver software just provided their own icon.

permanent link

Sent: Sat Oct 17 00:45:24 2020

Hi, tried running Mini vMac but keep getting a "unable to locate ROM image error"

status : responded

Please see the Getting Started with Mini vMac instructions.

The relevant sentence is:

To get past this, drag the icon of your ROM image file, “vMac.ROM”, onto the Mini vMac window.

permanent link

Sent: Sun Oct 4 09:30:41 2020

Hi Paul... I've been having a bit of trouble getting Mini vMac to auto load (find) my rom and dsk images on my Mac. It works fine on my PC, but I can't seem to get it to work with the same setup and files on the Mac. I started a post about it on the emaculation forums, but wasn't sure if you still stop by there. If you can offer any advice I appreciate it.

status : responded

Most likely this is because of “Path Randomization” misfeature added in macOS Sierra (10.12). See OS X notes for Mini vMac.

permanent link

Sent: (via email) Sun, 27 Sep 2020 13:50:13

Paul Pratt,

Okay I see,

Yes, I moved CopyRoms into the applications folder and it gave me back a 1.00 MB (1,048,576 bytes) file - success.

Sadly vMac says the checksum failed.

Here is the checksum on the new ROM file:

E:\Virtual Machines\minivmac-36.04-wx64.bin>C:\tools\sysinternals\sigcheck.exe 
-h PB165.ROM

Sigcheck v2.73 - File version and signature viewer
Copyright (C) 2004-2019 Mark Russinovich
Sysinternals - www.sysinternals.com

E:\Virtual Machines\minivmac-36.04-wx64.bin\PB165.ROM:
        Verified:       Unsigned
        File date:      1:49 AM 2/6/2040
        Publisher:      n/a
        Company:        n/a
        Description:    n/a
        Product:        n/a
        Prod version:   n/a
        File version:   n/a
        MachineType:    n/a
        MD5:    A495708975AEF7E23E78358547DE5F23
        SHA1:   C0510682AE6D973652D7E17F3C3B27629C47AFAC
        PESHA1: C0510682AE6D973652D7E17F3C3B27629C47AFAC
        PE256:  D43EB16CE4719D96C45BE61737B497918C4EBE27640A7AAFA058B7706971BD1C
        SHA256: D43EB16CE4719D96C45BE61737B497918C4EBE27640A7AAFA058B7706971BD1C
        IMP:    n/a

I appreciate it. I look forward to hearing back.

[... name ...]

[previous message]

status : responded

Checking the md5 against the 680x0 Macintosh List indicates you have successfully acquired the PowerBook 165 ROM image.

However, this ROM image will not work in the Macintosh Plus emulation of Mini vMac. Renaming it to “vMac.ROM” will not help.

Unfortunately, Mini vMac can not emulate a PowerBook 165 (or PowerBook 165c). To make this clearer, I have edited the 680x0 Macintosh List to put the “Supported by Mini vMac” line at the beginning of each entry, and to add an explicit “Supported by Mini vMac: no”, instead of just omitting this line.

permanent link

Sent: (via email) Fri, 25 Sep 2020 00:36:04

To whom it may concern,

Great little program. I just started learning how to make floppy disk images. I am a forensics student at [... school ...]. It would be great to see how software is made for these [...] operating systems.
I wanted to get the ROM off of a Powerbook 165C. It didn't create a file called "Unknown.ROM". It did create a 0 byte file called PB165.ROM. It wasn't crazy at least, yet as I understand it if the hash isn't in the list it isn't supported.
I'll provide the hashes from sysinternals/sigcheck.exe.
I am not sure these are necessary on a 0 byte file. If I can help any other way let me know.

        Verified:       Unsigned
        File date:      12:06 AM 9/25/2020
        Publisher:      n/a
        Company:        n/a
        Description:    n/a
        Product:        n/a
        Prod version:   n/a
        File version:   n/a
        MachineType:    n/a
        MD5:    D41D8CD98F00B204E9800998ECF8427E
        SHA1:   DA39A3EE5E6B4B0D3255BFEF95601890AFD80709
        PESHA1: n/a
        PE256:  n/a
        SHA256: E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
        IMP:    n/a

Thank you.
[... name ...]

status : added to documentation

The most likely reason CopyRoms failed is that there wasn’t enough free disk space. 1 megabyte (= 1024K) is needed for the PowerBook 165c ROM.

An excuse for why CopyRoms doesn't display an error dialog is that it is designed to work without a keyboard, mouse, or even screen.

It could be changed to create a file containing a useful error message. But running out of disk space is about the only error that could occur where an error file might be successfully written. And then looking for that error message would need to be documented. It might be simpler to just document that a zero length file means not enough disk space.

So I have done that, adding a paragraph to the CopyRoms documentation.

update - follow-up message

permanent link

Sent: (via email) Mon, 21 Sep 2020 23:17:38

I'm not sure how much you check Twitter, so I'm emailing you too. After some time debugging, I found out why Winter Games doesn't work in Mini vMac (and fixed it):

Wintergames modifies the VBL queue directly, inserting its own task at the head instead of calling VInstall, but it doesn't account for the possibility of the queue being empty, since on a real Mac the queue would have the task installed by the .Sony driver to track the disk speed (I think that's what it does, it's DT81 under P_Sony_FigTrkSpd in the Mac Plus ROM disassembly).

I fixed it in the replacement .Sony driver, by adding a task that does nothing to the queue, similar to how the time task is already added.

You can find my fix here, I'd be glad for it to be included in a future version of Mini vMac:

status : patch merged

Thanks! That’s impressive debugging. The patch is now merged into my development version.

I’ve made a few changes. Moving the VInstall block before the conditional branch instead of after allows it to work in Macintosh 128K emulation. Putting the record for the VBL task into the SonyVars structure instead of calling NewPtr may help minimize differences from previous versions. Changing the VBLTaskFreq to once a minute (instead of the maximum of about 9 minutes) may make it easier to notice if this task is having any unexpected effect.


Older Mail (Index)

www.gryphel.com/c/mail/v12 - feedback
copyright (c) 2020 Paul C. Pratt