UltraVNC

One simple thing that needs to be added still: A check to ensure that the API version of the plugin being loaded is matched for the app. It's easy enough to do: Require that plugins export something like "int getApiVersion()". Anything that doesn't export it is obviously the old pre-refactor code ...

As mentioned elsewhere -- I've acquired part-time access to a copy of MS VC++, and so have been able to get the miscellanious patches I threw together earlier to where they *actually work*. The corner cases still aren't tested carefully, but at least it works. [syntax="c"]Index: DSMPlugin/DSMPlugin ...

So, I've acquired part-time access to a copy of VC++, and come up with the following, improved (read: actually tested and working) patch: [syntax="c"]Index: winvnc/winvncsc/Localization.h =================================================================== RCS file: /cvsroot/ultravnc/ultravnc/winvnc ...

This is completely untested, because I don't have a copy of Visual C++... [insert usual griping about projects requiring proprietary tools to build here]... [syntax="c"]Index: Localization.h =================================================================== RCS file: /cvsroot/ultravnc/ultravnc ...

Per subject. I'm testing with UltraVNC SC using a repeater to communicate with the client. When it's unable to resolve the DNS name of the repeater, it pops up a message box titled (roughly) "WinVNC usage" containing the parameters being used. I find this error message to be substantially misleading ...

A patch demonstrating the style of API I prefer is available at: http://www.ecst.csuchico.edu/~cduffy/UltraVNC/DSMPluginRearchitect.patch It's not complete: I don't own Visual Studio, and my patch to reimplement Borland support doesn't extend to DSMs (and, for that matter, I haven't really tested it ...

I'm fairly positive that compiling the vnc code and your developed plugins into one package actually constitutes modifying it, and hence that would be a no go - but if you distributed Uvnc with your developed plug-ins you should be fine provided that you either distribute the source of Uvnc or make ...

Easy to do, actually, but not without breaking backward compatibility at the API level, as at least one more param needs to be passed to the functions (like caller process ID or something or pointer to a context buffer as you suggest). Just to clarify: The pointer is a void**, initially null, which ...

But of course it works with only one viewer using the plugin as no dll needs to be copied in this case. Erm -- unless I have a viewer running I don't know about (and I'm pretty sure I don't), it *doesn't* in fact work with only one viewer, as it attempts the copy anyhow in this situation. The ...

Even if none of that is practical: Exactly what is the issue that copying the DSM to a new file is intended to fix? It might be worth parameterizing the workaround's use if the bug that it fixes isn't as bad as the resultant "can't-use-DSMs-at-all" issue that unprivileged users end up with. (If ...

I can't make a copy in another directory because the plugin must be in the viewer's directory. There's no way around that? I don't know much about dynamic loading on Windows, but using dlopen() on UNIX, one can provide an explicit full path to be used. Poking around on MSDN, it looks like one can ...