Mac Question(s)

[B]

I just remembered that one of the things I need is Mac support, but I haven't tried ChunkVNC to/from a Mac yet.

1. Will the InstantSupport.dmg ever be able to be automatically recreated at compile time, just as the InstantSupport.exe is? (At least on my copy, it doesn't seem to change.)

2. Similarly, will the manual step to change server.txt for OSX be made slicker?

3. Is the Mac side of things being developed in concert with the Windows development?

4. Any chance of reworking the "reserved" repeater ID number scheme? As I may have mentioned before, it seems a little counterintuitive to have those reserved ranges for Mac and Windows; at first using all 1s as a test kept me from using Chunk from Windows to Windows due to conflict with the MSRC4 key. (Also, are you still keeping to the 6-digit rule by default?)

Looking forward to new versions, and with thanks...

-- B

[supercoe]

Mac support is considered "functional beta".
I've tested successfully with it in my OSX 10.4 virtual machine and a 10.5 Macbook.

1. Will the InstantSupport.dmg ever be able to be automatically recreated at compile time, just as the InstantSupport.exe is? (At least on my copy, it doesn't seem to change.)

No, mainly because the Mac version has nothing to do with the AutoIt programming language (AutoIt creates InstantSupport.exe). It's also very difficult to create Mac disk images in Windows without a 3rd party tool such as TransMac.


2. Similarly, will the manual step to change server.txt for OSX be made slicker?

Possibly in the future, I haven't been able to find a reliable way to edit a Mac disk image (.dmg) from Windows.


3. Is the Mac side of things being developed in concert with the Windows development?

Being that it's a completely separate implementation (Shell script + x11vnc vs. AutoIt + UltraVNC) it's basically a different project. My main focus currently is on the Windows version.


4. Any chance of reworking the "reserved" repeater ID number scheme? As I may have mentioned before, it seems a little counterintuitive to have those reserved ranges for Mac and Windows; at first using all 1s as a test kept me from using Chunk from Windows to Windows due to conflict with the MSRC4 key. (Also, are you still keeping to the 6-digit rule by default?)

The different ranges need to exist. Mac InstantSupport uses x11vnc which isn't compatible with the UltraVNC encryption plugins. The only way ChunkViewer knows to start with or without encryption is to restrict Windows and Mac ID's into separate ranges.

I believe the repeater can handle any 32bit integer, I stuck with 6 digits because it fit well on the screen.

Currently the plan is to remove the need to pass ID's all together and have ChunkViewer "know" which clients are running InstantSupport.

[B]

Interesting; thanks for the detail! I didn't know it was such a problem; the more I work with OSX the less I like it. (Even for 3rd party apps -- Entourage won't open PST files from the same company's other mail software!)

Hmm, but who says it has to be a DMG? Couldn't it just as easily be distributed in a ZIP file, which COULD be easily rewritten in Windows?

http://guides.macrumors.com/Installing_ ... n_Mac_OS_X


Edit: If it's any help (though it probably isn't) here's how the Gitso project compiles its DMGs for its similar application.

http://code.google.com/p/gitso/wiki/BuildOSX

[supercoe]

I picked DMG over ZIP mainly for ease of use. Everyone seems to have an unzip software that works differently, DMG's always mount neatly the same way.

As far as the Gitso project, they use py2app which currently doesn't run on Windows.

[B]

Okay. I still don't spend much time in OSX, but apparently ZIP handling is "native", so the Mac install side should be standard.... If you were talking about the Windows side of things, just including the gzip libraries or gzip command line in the ChunkVNC compiler would probably suffice. All we're really doing, I think, is replacing that single server.txt file?

I'm not trying to tell you what to do, of course -- just trying to tease out some ideas.

[supercoe]

ZIP handling is native in Windows since XP as well but you'll still run into having to "deal with" people having a variety of unpacking programs.

I guess it's just me trying to stay away from customers with 3rd party ZIP apps. I'd rather not have to explain to them extra steps just to get InstantSupport working.

You also run into many more IE "Are you sure you want to run this program" run boxes when you package ChunkVNC into a ZIP.

I'll look into packaging Mac InstantSupport into a ZIP again, I really can't remember the other reasons I picked DMG...

[B]

Maybe you're missing my point?

The gist of my suggestion was this:

1. The ChunkVNC compiler puts together the InstantSupport.exe as it does now, using user-supplied repeater info.

2. The ChunkVNC compiler uses the same repeater info to create a server.txt file for the Mac version.

3. The ChunkVNC compiler launches a bundled copy of gzip.exe to create an InstantSupportMac.zip

4. Optionally, and preferably, it does something like this for the repeater as well, if the user has changed the default ports.

5. Admins give the InstantSupport.exe to their Windows users, and the InstantSupportMac.zip to their Mac users.

There's no need at all for admins or users (Windows or Mac) to directly invoke ANY zip handling program. The only time that comes into play is when the Mac end user opens the ZIP (presumably using the OSX default viewer) and drags and drops (or just runs?) the application into his or her Apps folder.

[supercoe]

(presumably using the OSX default viewer) and drags and drops (or just runs?) the application into his or her Apps folder.

That right there is what I was talking about, you can't expect the OSX default ZIP manager. You can presume that everything will work as expected with a DMG.

What you've suggested in creating a ZIP for Mac InstantSupport would work, there were more reasons why I chose DMG over ZIP I just can't remember them right now. I'll get back to you on this subject when I get a chance to work on it more.