My configuration: Macintosh SE/30, System 7.1, MacTCP 2.1, connected via LocalTalk and an AsanteTalk LocalTalk-Ethernet Bridge to an Ubuntu server running macipgw. Using MiniVNC from https://github.com/marciot/mac-minivnc/releases/tag/v0.9-beta-march-19.

If I start MiniVNC immediately after booting my Mac, it appears to successfully open the driver and says it is listening for connections, but I am unable to connect

If, before starting MiniVNC, I use another TCP/IP application (e.g. open a connection with NCSA Telnet), I am able to connect to MacVNC as expected and everything works well.

This suggests to me that MiniVNC might be missing some kind of initialization step that my (admittedly rather unusual) network setup requires. I'll do a bit of further investigation myself as time permits, and I'm happy to help any way I can to debug this, but I just thought I'd put something out there before I forgot.

Thanks for writing a neat and potentially very useful tool!

Is there a list of compatible clients?

So far I've tried:

• MacOS' built-in VNC view which asks for password (I don't recall ever setting one) and then eventually times out (MiniVNC states Sending VNC Security Handshake before stopping the service when the client times out)

• TightVNC (on Win10) seems to connect, showing a 1x1 desktop while MiniVNC states the same 'Sending VNC Security Handshake' before TightVNC just exits and MiniVNC just goes back to 'Waiting for connection'

• MiniVNC server runs on PowerBook 520c (64LC040, 20MB, BlueSCSI v1 PicoW WiFi) with OS 8.1 and OpenTransport 1.3.1

• MacOS client runs on

  • 2012 Mac Pro with OS 10.14.6
  • 2010 MacBook Pro 13 with OS 10.14.6
  • 2005 iBook G4 with OS 10.5.8

• TightVNC client runs on

  • ~2011 Ivy Bridge desktop with Win10
  • ThinkPad X230T with Win10

When I connect using the realvnc viewer, I get this result. I'm less concerned about it not working and more about the infinite loop :-).

I think what's going on here (though this is only from a brief read-through of your code) is:

• -40 is, I think, "read beyond end of data" (though I may be misremembering here).
• Looking here: https://github.com/marciot/mac-minivnc/blob/main/mac-cpp-source/VNCServer.cpp#L382, this default does not set msgSize, so it stays as it was for the previous message, and breaks out of the switch, but not out of the loop.
• So it's going to keep trying to read from a closed TCP connection a message that'll never come.

You mentioned on the MLA some time ago that you were having some lingering stability issues. I found a possible reason for this. Completion routines run in an interrupt context and therefore are not allowed to move memory or to call toolbox routines that move memory. Your completion routines call ShowStatus, which eventually thunks down to SetIText, which can indeed move memory. This means that the application will be fine up until the application heap gets either full or fragmented, whereupon the Memory Manager will attempt to do something clever and your application heap will get corrupted.

(this occurs doubly with the SIOUX/printf stuff, which does even more clever stuff than SetIText does).

Suggestion: you could either look at using a queue to do this (see Enqueue/Dequeue in OS Utilities) or just a global variable to communicate with your main event loop, then do all the SetIText-ing from the main event loop, where the memory manager is working properly.

I don't know if these should be broken out individually, but these would be some nice-to-haves:

• remove the logo and put the name in the title bar (which should also allow 'MiniVNC' to show up in CMD+TAB)
• allow roll-up to hide the window
• maybe compact the UI to take up less space on small resolution screens?
• alternate control strip version to hide it away? or extension to load early in boot?