Compatible clients?

[reukiodo]

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

[marciot]

IIRC, when developing this I used RealVNC

[reukiodo]

Yeah! Connection! At least the mouse moves around on the real screen. Is there any special settings needed to get display working?

[reukiodo]

I've tried with various combinations of:

• neither Stream Display (SD) nor Incremental Updates (IU)
• SD but not IU
• not SD but IU
• SD and IU

None of these resulted in the client showing anything but black ... and maybe that little gray bar at the top? I'm not certain what this is as this is my first time using RealVNC Viewer.

[marciot]

Which executable did you run? IIRC, there are multiple executables for different Macs. I have never tested on a PowerBook 520c, so it is possible it simply does not work. You may also have to change the color modes, that might improve compatibility.

[reukiodo]

RealVNC-MiniVNC.pcapng.gz TIghtVNC-MiniVNC.pcapng.gz

I finally got around to installing Wireshark on my desktop to capture the network packets.

There's more than one? I'm using the one from https://github.com/marciot/mac-minivnc/releases/download/v0.9-beta-march-19/MiniVNC.v0.9.sit.hqx

[reukiodo]

Ok, just deleting the App and re-downloading the file and extracting it again seems to work now:

[reukiodo]

Am I correct in that the RLE encoding is the paid/sponsored version?

[marciot]

MiniVNC only supports Palleted Tile RLE encoding. Vintage Macs are severely bottle-necked by the CPU, so compression isn't very practical. I do provide some experimental versions in my archive for sponsors, but they don't necessarily perform any better due to CPU limits.

If you want the details, you can expand the Technical Notes section on the main GitHub page and read all about the compromises I had to make.

[reukiodo]

Ah, so most likely these other clients do not support this PTRLE ?

[marciot]

Ah, so most likely these other clients do not support this PTRLE ?

Possibly, although since the Apple client fails at handshaking, I believe something else is up there.

[reukiodo]

I tried a RealVNC Viewer 3.1.4 compiled for Windows ARM64 and it is also unable to connect.

[reukiodo]

Win10arm-MacVNC.pcapng.gz

[marciot]

@reukiodo what kind of performance are you seeing with this? Is it something you would consider using?

MiniVNC was meant as a technical demo for very early Macs like the Plus and I hardly ever expected it to be useful (especially since MacTCP is notoriously unstable). Yet, most comments I've gotten on it seem to be from people running it on much later Macs. If that is the primary use case, it might make sense for me to someday try to improve compatibility.

[reukiodo]

I mean, it's slow by modern standards, but it's usable and useful. I've been testing it on the PB520c mostly because it's the easiest to test around with. I haven't had any dropped connections, and both sides are wireless (BlueSCSIv2 PicoW in the 520c) which is more notorious for packet loss than wired.

My main goal is to put it on my Quadra 610 (68040) because I plan to run it mostly headless, and that'd be wired up to ethernet, not wireless.

My Classic (68000), SE/30 (68030), and 520c (68LC040) all have built in screens and unless they burn out or fail, MiniVNC is more a nice-to-play with than a daily use.

[reukiodo]

This is a realtime video captured from Win10 (gamebar) of the RealVNC Viewer client after connection to the 520c: https://github.com/marciot/mac-minivnc/assets/5169351/b732af9b-593c-4734-a303-acfe1a19bbeb

So sure, it is slow and doesn't really compare to modern equivalents with much larger resolutions and deeper colors, but it works well enough to navigate around and open files. I'm not going to play any games through it, but it lets me manage the system and open documents and such.

[marciot]

Okay, so I've been doing some work with this and have been trying to understand why these various alternative clients fail. Here is what I have learned so far:

• TightVNC fails for two reasons, it does not support TRLE encoding and it does not support indexed color mode (i.e. color palettes).
• macOS Screen Sharing seems finicky during handshaking -- it requires a password and even when I try implementing that, it fails

[reukiodo]

even when the password is blank? that seems odd...

[reukiodo]

How can I help identify different VNC clients in their support for TRLE and/or indexed color mode? Is this something one could easily identify in the pcap with Wireshark? Or is it more complicated in that it requires running the server in debug mode?

[marciot]

The way VNC works is the server provides a list of supported encoding, and the client replies with which one it wants to use. At no point does the client send a list of encodings it supports on the network, so a session capture would not tell you that.

The only way to have a client divulge it does not support TRLE is for the server to only provide that in the list of accepted protocols, and for the client to fail. I've been revisiting MiniVNC these last few days and have a new version in the works with much better logging, but it's still pretty raw so I don't want to share it quite yet. I have started to compile a list of tested clients here:

https://github.com/marciot/mac-minivnc

If you have any others you want me to look at, let me know. I've also started to evaluate the feasibility of supporting Hextile in MiniVNC, as TRLE has very, very poor support.

[marciot]

@reukiodo Please ignore what I just said. What I said is true about authentication methods, but encodings are sent from the client to the server and can be captured. Here is what it looks like:

Encoding 15 (RRLE) is what MiniVNC uses.

TrueColor false (indexed color) is what MiniVNC needs.

[marciot]

@reukiodo I've made significant strides with the next version of MiniVNC. Here it is working with the TightVNC client using the brand new Hextile encoder and true color mode:

This makes it compatible with TightVNC, MacVNC and VNCThing.

[marciot]

@reukiodo Please check out the v1.1 release, as it is far, far more compatible!

[reukiodo]

I missed 1.1 but 1.2 UI is looking sweet! Performance with RealVNC seems on par with the old 0.9 and worse with TightVNC but at least it works now! I love that the window can be closed away without killing the app!

[reukiodo]

Though MacOS' Screen Sharing always asks for password and I can't seem to get it to connect no matter what I try... ☹️

[reukiodo]

Weird, after a few attempts to connect with Screen Sharing, now TightVNC asks for a password too, though it connects after providing no (blank) password.

[marciot]

Screen Sharing is very problematic, it’s not a particularly compliant VNC client. It fails to connect unless the server asks for a password, so as a workaround I detect a failed connection and enable authentication for subsequent connections. This is why TightVNC will ask for a password after Screen Sharing tries and fails to connect. On the version I tested it on, this lets Screen Sharing connect, but it’s a 2011 Mac running a fairly old version of Mac OS X. More recent versions of Screen Sharing probably fail for different reasons.

Anyhow, you’re not missing much. Screen Sharing only supports ZRLE and 32-but color, meaning it has the worst possible performance when connecting to MiniVNC on older Macs. Not much to write home about.

[that-ben]

This project is incredible! Congratulations on making this. It works great on my Mac IIci but only via TightVNC and RealVNC Viewer.

Under TurboVNC, it crashes MiniVNC on the Mac IIci and I have to reset the CPU.

Also, excuse me, but the fact that my iPhone can remotely control my Mac IIci from 1989 is nothing short of mind blowing to me. If you had asked me if this would be possible 5 years ago, I would have thought that this would never, ever happen. Yet I'm doing it today via RealVNC Viewer on my iPhone 13 and it works great. It's absolutely shocking.

[marciot]

@that-ben: I've been working on a nearly complete redesign of MiniVNC since January and it's been such a massive rabbit hole of a project that at times I doubted my sanity in pursuing it. So, thank you, your words of encouragement mean a lot to me! The next release, which I hope to wrap up in March, should improve performance even further and decrease memory use significantly, especially for ZRLE. I also suspect compatibility with clients will improve. So keep an eye out for that!

Past that release, I do have some wild ideas for a future MiniVNC. I would love to see it support file transfer, and I'm also considering a web interface with a Javascript client, so that way third-party viewers would not be needed at all! Again, it is comments like yours that keep me going, so thank you!

[that-ben]

Oh yeah, and this is extremely fun to see as a retro hobby project.

I want to add here that MiniVNC does not run under Mac OS 9.2.2. I just tried it on my iMac G3 DV+ and it freezes the iMac G3. I use another VNC server app under Mac OS 8 and 9, so it's OK, there are other options already. But I would have liked MiniVNC not to crash the whole computer.

I think the problem with TurboVNC and overall crashes after a connection is that all the compression/encoding methods that the client supports are unsupported by MiniVNC. In the case of TurboVNC, all it supports is a mixture of Tight + something like ZIP or JPEG. There's no HexTile or RAW support I believe so I think that's why MiniVNC freezes and TurboVNC remains on a black screen... Perhaps you should catch that exception in MiniVNC? Like you could print something in the log window and disconnect when the client does not have a compression method that's useable by MiniVNC.

[marciot]

Interesting. I can maybe spin up Mac OS 9.2.2 and try troubleshooting the issue. Thank you for letting me know. I'll also try out TurboVNC, but I suspect that there won't be any protocols that will be compatible. I just don't think an older Mac can support JPEG in real-time, or compress a lossless stream with ZLib.

Implementing a HTML/Javascript interface would avoid all these shenanigans as I could choose the best protocol for the classic Macs (currently TRLE) and not worry about clients not supporting it. But this is also a bit of a rabbit hole of a project as it would involve adding a modern web server with WebSockets into MiniVNC 🤣

[that-ben]

Oh heck no, my old Mac would not be able to encode JPEG in real time, I mean my Mac IIci BARELY redraws at 1fps and that's on the lowest RealVNC Viewer quality setting so forget about ANY kind of compression on that Mac IIci haha! But it's just pure magic seeing this, even at 1fps! It's almost mesmerizing 😵‍💫

Anyway, TurboVNC is a great VNC server and one of the only option under macOS Sonoma that lets you have reverse VNC connections without too much hassle. It's also one of the open source VNC clients that automatically resizes the viewer correctly. I tried TightVNC under macOS Sonoma first and it was almost unusable and did not support reverse VNC connections like it does under Windows. So in a nutshell, it would be great addition if MiniVNC supported TurboVNC, but if TurboVNC client can't do HexTile or even RAW, I don't see this happening at all when paired to old 68K Macs, unfortunately.

[marciot]

@that-ben: Do you want to try the version I have been working on? I am curious whether it behaves any differently on your IIci:

MiniVNC v1.3 alpha 2-28.hqx.txt

Consider this alpha quality at this point. There might be bugs.

[marciot]

I just tried TurboVNC with v1.3 alpha and it won't connect (expected) but it does not crash the server. Maybe the crash was fixed in this alpha.

[marciot]

Nevermind, it hadn't actually connected. I see it crashing now.

[marciot]

@that-ben: It looks like the reason TurboVNC crashes MiniVNC is that I never implemented the ClientCutText message that is used to transfer the clipboard contents. TurboVNC sends this very early in the connection and it causes MiniVNC to crash. This may explain why I would get random crashes with other clients too. Thanks for bringing this major oversight to my attention.

In other news, it looks like TurboVNC does support the standard non-compressed encodings, so as soon as I fix the crash it should work fine as a client with MiniVNC.

[marciot]

@that-ben: Okay, TurboVNC is now fixed. As a bonus, you can also now copy from the local client and paste into the remote Mac. Here is the alpha version with the improvements:

MiniVNC v1.3 alpha 2-28 r2.hqx.txt

[that-ben]

Dude, you're SO QUICK at implementing this! It's crazy. I posted a message before going to bed, I wake up and there are 5 messages in a row stating you had found the bug and resolved it. Now that's incredible dedication!

I will try this when I come back from skiing ❄️⛷️🌲⛰️ and let you know my findings. Thank you so much for taking care of this and so quickly too! I think you deserve a donation, but I cannot donate through GitHub. Do you have a Paypal account in which I could push a little something for you?

[marciot]

@that-ben: I'm glad MiniVNC has been helpful to you. You can donate through my Patreon or my PalPal here

[that-ben]

Donation sent! 😃 I will be trying out the new MiniVNC alpha soon! (note: please fix your "my PayPal here" link so that it begins with https:// because right now it's a relative link and it fails. Of course, I manually fixed it on my side to reach your Paypal page, but I'm telling you so other users can more easily use that link if they want to donate)

...One Eternity Later... (jk)

I got to test it on my Mac IIci and it works under TurboVNC when using HexTile mode!!! THAT IS GREAT! 🥳 ...It's SO SLOW! It's about 1 frame per 5 seconds (0.2fps) haha! BUT IT WORKS! Incredible!

Note that it does not work in RAW. The cursor moves, but TurboVNC screen remains black. I also tried image quality 1/10 and it still doesn't stream in RAW under TurboVNC. The issue with this is that if you don't know this and MiniVNC options has both RAW and HexTile checkboxes checked, then TurboVNC will try to use RAW and so the screen will remain black. I had to uncheck RAW in MiniVNC for TurboVNC to try and use HexTile.

On the PowerPC side of things, under Mac OS 9.2.2, MiniVNC crashes with a type 1 error and a memory leak that cannot be overcome unless I reboot my iMac G3. There is no way to attempt to reconnect without a reboot first. On the TurboVNC client, I get this error with all encodings checked in MiniVNC options on the iMac G3 and then I tried only RAW checked and then only HexTile checked, all of them do exactly this:

[marciot]

@that-ben: Hi Ben, I made a new release, there have been some fixes since the alpha version I sent you earlier. Can you let me know if it solves the issues you identified?

https://github.com/marciot/mac-minivnc/releases/tag/v1.3-beta-mar-3-2024

[that-ben]

Wow another release!? Awesome! I'll try this later today and I'll be sure to report on here! Thanks!

EDIT: I have tested v1.3-beta-mar-3 and it works great in HexTile! I'm getting about 1fps which a little bit faster than the previous version that I tested. Now, if both RAW and HexTile are selected in the MiniVNC options, both TurboVNC and RealVNC Viewer on iOS correctly prefer and use HexTile. Though, if I were to only allow RAW in the MiniVNC options, then TurboVNC would still not work and only display a black screen. I guess it's fine as at least it prefers HexTile to RAW, so that's working fine by default now.

On a PowerPC running Mac OS 8.6 there is progress with v1.3-beta-mar-3 as it no longer freezes MiniVNC. RAW does not work (black screen just like on 68K) but HexTile seems to work... for a couple seconds and then the connection closes with this error on TurboVNC:

I tried disabling JPEG compression and various compression levels, but they all work for a short period of time and then crash (within 30 seconds). I think it crashes when I click on the desktop, not exactly sure what causes this.

Note that it also crashes under RealVNC Viewer on iOS after a few seconds and/or clicking on the desktop... it's probably for the same reason, but it does not say:

Either way, it's definitely good progress as none of the viewer and the server are freezing so that's a major improvement over previous versions!

[marciot]

@that-ben: I'm sorry I missed this update and did not respond, I've just released MiniVNC 1.4, could you maybe see if it made a difference with any of these issues? If it is still happening, I can investigate. Thank you!

[that-ben]

I will be trying this out this weekend for sure! Thanks Marcio for keeping up with this incredible project :)

[reukiodo]

Wow! That's cool for TightVNC!

[that-ben]

Alright, I gave v1.4 a try!

First off, now it always tries to use HexTile without any compression (no ZLIB, no JPEG encoding) when I connect from TurboVNC, regardless of the checked encoding options in MiniVNC. This is an improvement over v1.3, since it avoids the crash that occurred when the client (in my case TurboVNC) preferred JPEG, RAW or ZLIB. This is very good.

The bug with clients crashing when I click on the desktop still occurs randomly (but quite frequently) under PowerPC (Mac OS 8.6). For example, screenshot below happened 3 times in less than 2 minutes of use under the TurboVNC client. I'm trying to isolate this issue a little further. I will post more details here after I do more testing. When this happens, there is nothing added in the MiniVNC log and it looks like MiniVNC thinks it's still connected, so I think this happens whenever MiniVNC returns some DATA to TurboVNC that TurboVNC does not like.

Under RealVNC Viewer on mobile, it was more stable and I only got disconnected once after 3-4 minutes of solid use. I clicked everywhere, toggled between open applications, drew rectangles on the desktop, etc... it was overall more stable than TurboVNC from my iMac M3.

Performance wise, I don't see any improvement over v1.3b. I still get a little less than 1fps under v1.4 on my Mac IIci and approximately 4fps (which is absolutely acceptable and workable) on my PowerMac 7300.

All in all, it's a little more stable :)

[reukiodo]

a web interface with a Javascript client, so that way third-party viewers would not be needed at all!

This is probably the most optimal, as you could then force the client to support the best possible configurations for server-side performance and the client could have wide compatibility on any platform.

would involve adding a modern web server with WebSockets into MiniVNC

Couldn't the JS VNC client just connect on the standard VNC port though? A simple http server serving static content should be enough for the client.

[reukiodo]

https://blog.mgechev.com/2013/08/30/vnc-javascript-nodejs/

"The Node.js server will stay between the browser and the VNC server. We need it because the client-side JavaScript does not supports TCP sockets so we can’t connect directly to the VNC server."

Ah, answered my own question - nevermind me!

[that-ben]

^ This is blatantly outdated information from 11 years ago.

If it were 2013 again, I would reply with: VNC should truly use an UDP model instead of TCP. It would increase the redraw rate, IMO... and since we do not care for transaction sequence order, but truly only want as many little tiles redrawn as possible, then TCP doesn't make any sense, unless of course it uses the WebSocket protocol (which web browsers can use without the help of any in-between servers of any kind) then it's as fast as UDP.

But in a nutshell, where it's at in 2024 in terms of performance and compatibility is: WebSocket over TCP. If you want security (which you probably do) then just use its sister tech: WebSocket over SSL (WSS) which again, is supported out of the box by all web browsers without the need for anything in between. It will gladly connect to any port you want, including 5900.

I have yet to try this web VNC client with MiniVNC, perhaps I will try it tomorrow when my PiSCSI battery is charged up: https://novnc.com/noVNC/vnc.html

[marciot]

The bug with clients crashing when I click on the desktop still occurs randomly (but quite frequently) under PowerPC (Mac OS 8.6).

I have a PowerBook 3400c that runs MacOS 8.6. Could you send me a link to the exact TurboVNC client you are using so I can try reproducing the problem? Is there a page on MR where I can download it?

Also, for clarity, can you reiterate where you are running the server and client? What is the system and OS on both ends?

Performance wise, I don't see any improvement over v1.3b. I still get a little less than 1fps under v1.4 on my Mac IIci and approximately 4fps (which is absolutely acceptable and workable) on my PowerMac 7300.

Right, v1.4 was mostly reliability fixes, not expecting more performance out of it.

All in all, it's a little more stable :)

Every little bit of progress forwards is good progress!

[that-ben]

Could you send me a link to the exact TurboVNC client you are using

https://github.com/TurboVNC/turbovnc/releases/tag/3.1.1

Also, for clarity, can you reiterate where you are running the server and client? What is the system and OS on both ends?

TurboVNC 3.1 client is running on my iMac M3 (under macOS Sonoma if it even matters) and it connects to MiniVNC running on a PowerMac 7300 under Mac OS 8.6.