Compatible clients? #9
Comments
|
IIRC, when developing this I used RealVNC |
|
Yeah! Connection! At least the mouse moves around on the real screen. Is there any special settings needed to get display working? |
|
I've tried with various combinations of:
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. |
|
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. |
|
RealVNC-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 |
|
Ok, just deleting the App and re-downloading the file and extracting it again seems to work now: |
|
|
|
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. |
|
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. |
|
I tried a RealVNC Viewer 3.1.4 compiled for Windows ARM64 and it is also unable to connect. |
|
@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. |
|
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. |
|
This is a realtime video captured from Win10 (gamebar) of the RealVNC Viewer client after connection to the 520c: 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. |
|
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:
|
|
even when the password is blank? that seems odd... |
|
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? |
|
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. |
|
@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. |
|
@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. |
|
@reukiodo Please check out the v1.1 release, as it is far, far more compatible! |
|
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! |
|
Though MacOS' Screen Sharing always asks for password and I can't seem to get it to connect no matter what I try... |
|
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. |
|
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. |
|
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.
|
|
@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! |
|
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. 
|
|
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 🤣 |
|
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. |
|
@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. |
|
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. |
|
Nevermind, it hadn't actually connected. I see it crashing now. |
|
@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. |
|
@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: |
|
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? |
|
@that-ben: I'm glad MiniVNC has been helpful to you. You can donate through my Patreon or my PalPal here |
|
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 ...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: 
|
|
@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 |
|
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! |
|
@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! |
|
I will be trying this out this weekend for sure! Thanks Marcio for keeping up with this incredible project :) |
|
Wow! That's cool for TightVNC! |
|
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 :) |
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.
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. |
|
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! |
|
^ 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 |
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?
Right, v1.4 was mostly reliability fixes, not expecting more performance out of it.
Every little bit of progress forwards is good progress! |
https://github.com/TurboVNC/turbovnc/releases/tag/3.1.1
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. |
While it is not UDP, there is one VNC extension I want to implement that will help with latency. It is a continuous update extension. In regular VNC, the client has to request a screen update and the server can only send a frame in response to a request. This requires a round trip for each frame. The continuous update extension allows the server to stream changes as soon as they happen, without waiting for a client request. I believe this is well supported by clients and should decrease latency by a lot. As far as true UDP, I believe some VNC server/client combinations may support this, but I can't find documentation on it anywhere.
I am looking into the feasibility of adding WebSockets to MiniVNC. I think it can be done, but I'll need to make use the threading library I have been playing around with.
Right. I just learned yesterday that WS can connect to any host, even hosts other than the server that served the webpage it was hosted on. This is unusual since everything else seems to be subject to the so-called cross-origin security. This does simplify the task a bit, since I could implement a minimal WS server in MiniVNC without having to implement a full web server that could serve the client files itself. The problem, however, is that WS cannot connect to "raw" TCP sockets, only to web servers that support WS. So @reukiodo is correct that unless I add some WS support to MiniVNC, he would still need to use a WS proxy of some sort. |
|
We could probably use something like this to translate the WebSocket frames to regular TCP traffic? https://github.com/novnc/websockify
On MR, we have created and played 2 years ago with a WebSocket real time graphical chat app that looks a little bit like The Palace from 1995 where you can click around to move your avatar, draw collectively in real time on the background and display messages in a bubble next to you. As an example, it connects using WebSocket over SSL to port 9995 which is not a standard port. There is no security or cross-origin issue even if the WebSocket script originates from HTTPS port 443. https://www.macintoshrepository.org/the-castle/
|
|
@that-ben: So I've been running TurboVNC 3.1.1 (20240127) on macOS High Sierra, connecting to a PowerBook 3400c running Mac OS 8.6 and it appears stable as a rock. I cannot get it to crash.
Not to question the obvious, but did you maybe accidentally open the v1.3 of MiniVNC by mistake? Even if you didn't, I recommend rebooting just in case as I have seen instances where MiniVNC continues to run as an interrupt routine even after the main app has quit. There is a chance that if maybe you were comparing the two, that you ended up with an older one stuck in memory. |
|
@that-ben also, check to see if it has something to do with having data in the clipboard buffer. This is one area in which TurboVNC was crashing in the past and one thing that can make testing results seem inconsistent from one time to another. |
|
I am beginning to wonder if it's not the WiFi router that's causing this. I cannot ignore this possibility. I hate that ISP router and I'm considering replacing it with my own (like I had with my previous ISP). This new ISP claimed 2 years ago that I could do everything in their router, but by the end of last year, they actually locked down the whole thing with a firmware update and even after I called them, they would not revert the change so I'm stuck with a router that does funky things such as auto-channel tuning which I suspect is the issue at hand and possibly other things as well. I'll install my own router like I had 2 years ago and I'll re-test this once I actually have control over my WiFi network. I actually caught my brand new iMac M3 saying 2 times in 1 month that GOOGLE.COM was down and my PiSCSI drops out of WiFi after half an hour for no apparent reason. Sometimes, we're watching a show on our smart TV and when the ads are about to play, there's a network error, but when we refresh, it always works the second time. |
|
@that-ben I will add that MiniVNC may not handle things entirely well if network packets are fragmented en route. The more devices the packets go through, the more likely this is to happen. This is a hard situation to test for since it depends a lot on the individual devices that are forwarding the packets. Ron from Ron's Computer Videos said he was having some problems getting MiniVNC to work over Apple Internet Router and I suspect it might be a similar problem. It's on my TODO list to try making MiniVNC a little more robust to possible fragmentation. |
|
I have not seen any stability issues from my two typical uses: I've tried from other clients also, but not really for an extended time to determine if they are fully stable, more just a 'they can connect and click around the desktop' trials. |
|
@that-ben I am at a loss as to why you are having troubles with MiniVNC v1.4. These last few days I've been experimenting with tunneling TCP/IP over AppleTalk and even with the most convoluted network setup I could come up with, everything is working great. Here is my current setup:
So I am running a VNC session through WiFi, SCSI and LocalTalk; going through a WiFi router, a Mac LC II, and a Raspberry Pi; and involving three different versions of macOS on machines about twenty years apart. And, to my bewilderment, it all works just dandy! I just can't understand why it is not working for you 😢 |
|
I will try again with a different WiFi router in the near future. I'm planning to replace it once I finish a few important projects I've been working on. Once I re-test, I will post again here. Pretty sure it has something to do with that ISP router, to put it in simpler terms: it just svcks. I wouldn't worry too much about my case if I were you, since I'm highly suspecting my ISP router to cause other issues I've been having this winter as well. The picture gets clearer every week. Last week, I caught my W11 laptop to disconnect briefly from WiFi for a few seconds then reconnect. Something is off with that router for sure. |
|
Alright! So I FINALLY had time to rebuild my LAN with my own chosen router instead of the ISP's POS. Everything seems to work better now haha! I have been using it for an hour on both my Mac IIci and my PowerMac 7300/200 and it seems perfectly stable! |
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
TightVNC client runs on
The text was updated successfully, but these errors were encountered: