UltraVNC (LibXML2 MOD)

[shadowfax]

Hi,

This is the origina UltraVNC 1.0.9.6 but libxml2 has been added to it. Although not all of the code has been replaced yet from INI file to XML, the dialogs have started to use the XML file. In order to speedup the MOD most of the functions used for INI settings have been cloned for XML settings. I've only added "ReadBoolean" and "WriteBoolean" in order to get a clearer XML file. Hopefully it could add more flexibility to the configuration file.

The main structure of the XML file is similar to .NET app.config... In this case named "ultravnc.conf".

The bad news... Without twweaking libxml2 (Probably preprocesors will do most of the job here), the final executable size is 2.70 Mb versus 1.71 Mb of the original UltraVNC... I guess there is no use for Nano servers included in libxml2, and probably other things could be stripped away from it to get a lighter executable.

Why XML?

• Most of the INI functions are listed on MSDN as backward compatibility with windows 9x and could be removed from the API on future versions.
• More flexibility
• Could make use of a pseudo-RESX resource file.

resx is a "resource file" (Not quite) with an XML structure... Therefore, language strings, and maybe images (Although the editors will only link to a file on harddrive), could be created into a XML file and, therefore, get away from loading DLLs on the fly.

Although I'm not really sure if someone will find this usefull, just in case I've uploaded it to:
http://www.megaupload.com/?d=8LFSV33V


Best regards

[B]

I've much admired your previous ideas, shadowfax, but I think I dislike this one a great deal. Straightforward INI files are much preferable to either XML or registry hives.

[shadowfax]

Hi B,

More than an idea it's just a trial. I found it would be easier to give a test run chaning the configuration settings than running into RESX (look-a-like) files to store the localized resources. However, I find the size increase way too high only to achieve this goal. Maybe the filesize can be decreased by tweaking libxml2 precompiler conditions... But I'm not sure how far it will decrease the file size.

I agree with you on registry hives... Maybe because i have a little preference for portable applications and due to the fact some applications leave registry keys around that only decrease startup performance. However, I don't really see a great deal of diference between INI and XML file. IMHO, XML gives more flexibility than INI files since you can make a nicelly structured configuration file. For example, MS Logon data can be stored in a much more organized fashion than inside an INI file. However, INI files are suficient for most configuration needs. The good thing about INI files is that they are supported by Windows' API, making the application weight less... The drawback is that Microsoft has been focusing for years on XML styled configuration files stating in the API documentation it is only available for backward compatibility with Windows 95/98. So I'm not sure of the advantages and disadvantages to any of this methods to store configuration settings.

However, once again, the idea on adding libxml2 is more focused towards globalization through a kind of resx files. If the lib was included it could also be used for configuration files and I took that as a test. I certainly don't like the file size increase... As you know I use VNC most of the time for remote support and the lighter the executable file the better and it's certainly a great increase for the features it could add. However, I thought sharing the code would be nice since maybe someone finds a way to put on diet libxml2 and make a step forward to simple XML resource files... or even is just interested on investigating a little further.

I used 1.0.9.6 since I was just playing around to see the results. I thought the results would be helpfull to determine if it would be the way to go for information exchange between the repeater and the external site, plus information exchange between the client and the website (Changing JSON in favour of XML+SOAP)... but it bloads the executable

Probably some routers will have libxml2 build into them, as some routers such as pfSense and some Openfirmware linksys make use of libxml2 for the configuration files. That the reason why I tested libxml2 instead of lighter libraries... but for the meanwhile I think i'll stick to JSON as it is much lighter and I guess a Linux port of the repeater would stay at a reasonable size to run inside a router, ReadyNAS or WDTV (Mostly where I usually run a repeater) with JSON statically linked.

My goal is to use JSON or XML to exchange dta from the repeater to an external site, plus an external site to the client (such as telling the client it is not allowed to log in into the repeter and so on)... Instead of modifying the RFB protocol to fit my needs make it use HTTP requests to enhance some features. XML+SOAP seemed a good idea if file size didn't inrease so much.

[B]

You are in all likelihood doing the "right" thing; I'm just being an old fogey. But to me the major advantage of INI files is that they are so human-readable. Even if the variable names stay the same, in an XML file you have to draw your eyes through a mess of tags to read the thing. I think it's good you are focusing on the bigger picture...