Compatible clients? about mac-minivnc HOT 60 OPEN

@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

from mac-minivnc.

@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.

from mac-minivnc.

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

from mac-minivnc.

@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!

from mac-minivnc.

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

from mac-minivnc.

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.

from mac-minivnc.

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.

from mac-minivnc.

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

from mac-minivnc.

@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.

from mac-minivnc.

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

from mac-minivnc.

@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

from mac-minivnc.

@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!

from mac-minivnc.

IIRC, when developing this I used RealVNC

from mac-minivnc.

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

from mac-minivnc.

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.

from mac-minivnc.

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.

from mac-minivnc.

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

from mac-minivnc.

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

from mac-minivnc.

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

from mac-minivnc.

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.

from mac-minivnc.

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

from mac-minivnc.

Win10arm-MacVNC.pcapng.gz

from mac-minivnc.

@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.

from mac-minivnc.

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.

from mac-minivnc.

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.

from mac-minivnc.

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

from mac-minivnc.

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

from mac-minivnc.

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?

from mac-minivnc.

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.

from mac-minivnc.

@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.

from mac-minivnc.

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!

from mac-minivnc.

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

from mac-minivnc.

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.

from mac-minivnc.

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.

from mac-minivnc.

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.

from mac-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 🤣

from mac-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.

from mac-minivnc.

@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.

from mac-minivnc.

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.

from mac-minivnc.

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?

from mac-minivnc.

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:

from mac-minivnc.

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!

from mac-minivnc.

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

from mac-minivnc.