Convert to DLL or GAU, is it possible ?

[ias 0]

hi all,Is there any tool to convert cab or XML file into DLL or GAU ?

[n4gix 4,947]

No. They are totally incompatible methods. One uses compiled C/C++ code to create a module (dynamic link library). The other uses a simple ASCII script to drive the XML parsing engine, which in turn generates the "gauge action."

[Herbie63 0]

Bill is right, converting XMLs to DLL or GAU isn't possible. But they can be converted to SPB format, which can be used in FS-X. This gauge format offers a better copy/theft protection, allthough it isn't as secure as the others. The downside is, that the XMLs have to be in the newer FS-X style, which differs a bit from more simple FS9 style.Converting can be done using the ACE tool. distributed with the FS-X SDK.Herbert

[Guest JeanLuc_]

Actually this opens an interesting idea. With my new gauge framework, all elements in the gauge are dynamically created at runtime, and not statically linked like with the FS SDK. This means, provided we have a correct parser to runtime-interpret the XML code, I could be able to create an XML-Wrapper load-it-all generic .GAU/.DLL that loads an XML script, and run it from a compiled C++ .GAU (1st step). From then, we can think of a tools that embeds the XML source code (encrypted) in a compiled .GAU/.DLl done with my framework, in order to have a single executable.The neat thing is that this could permit extending the XML language with custom XML commands/elements/types that would be interpreted and rendered in real-time from the compiled C++ gauge code!If anyone is willing to start working on this project with me, I'd be glad to open the Framework to him and start working on such solutions. This could be great a solution: flexible and easy syntax of XML (or we can even think of BASIC or PASCAL - there are free pascal script interpreters available....) running in a secured and fast C++ rendering gauge core!What do you think?

[taguilo 33]

Hi,"This means, provided we have a correct parser to runtime-interpret the XML code, I could be able to create an XML-Wrapper load-it-all generic .GAU/.DLL that loads an XML script, and run it from a compiled C++ .GAU"Actually this is what panels.dll does :-) XML gauges are completely loaded when an aircraft is initialized, and the resulting code is procesed through panels.dll and functions like that of an ordinary C++ gauge. That's the reason those gauges are fast, almost as fast as their equivalents in C (with some exceptions, ie gdi drawing methods)I think this is probably the way it works:You have a dll (panels) that does something like:--Show()function Show() MyData="SOMETHING" Return MyDataNow interacting with XML:--Show()function Show() if not XMLLoaded MyData=LoadXML() Return MyData Mydatasaved = MyData else Return MyDatasaved function LoadXML() open file "A.XML" read line 1 (contains "SOMETHING") return line 1 This is only an idea, showed because I have the impression that people think XML files are processed continuosly at runtime, when they are not. That's the reason also the files are editable even when the sim is running. The slow part of XML system is the loading process, because fs9.exe converts the source into temp assembled files. This pass has been optimized by the possibility to use ACE editor to "compile" XML into .spb format, which is nothing more than pseudoassembled code with text ident scripts included. Those .spb files are quite smaller than their sources (because the code has already been optimized) and take less time to load, being of great help when dealing with complex XML panels.Tom

[Guest JeanLuc_]

Yes you are right, panels.dll loads a XML file and tokenize it, like Visual Basic used to do (i.e. it parse the source, convert the source to tokens, and then the tokens are "processed").Now, the catch is that tokens are just a pre-converted text to integer, i.e. it saves comparing strings during run time. Example, say you have a loop, interpreter would always read your "a = a +10" while the token interpreter would do "Add(var, 10)" which would be a function call, encoded in the form of (internally) : PROC_CALL PROC_ADD_TOKEN var 10This is alright and perfectly fast enough to display data on the screen, move images, and do maths (and my idea above wouldn't be faster, unless optimized further, because it would simply do the same as panels.dll in this respect).However, the idea goes beyond: adding / enhancing the capabilities of interpreted gauges with features that do not exists in XML gauges, like fast vector drawing, sound (I mean not using third party freeware very good solution that already exists), manipulating files and databases, reading config files and managing ini files, etc....+ possibility to have a user friendly code interpreter, using basic or pascal because XML for elements this is nice, but look at the GPS (default) XML code and imagine this code just in infix notation like Basic...This is a general idea of course!

[taguilo 33]

>>However, the idea goes beyond: adding / enhancing the>capabilities of interpreted gauges with features that do not>exists in XML gauges, like fast vector drawing, sound (I mean>not using third party freeware very good solution that already>exists), manipulating files and databases, reading config>files and managing ini files, etc....>I see your point. The Cabin Comfort .dll project in FSX SDK is a perfect example on how powerful could be a good interaction between XML gauges and a "server" C library (actually one can perform many of the actions stated above: read files, draw vectors, play sounds, etc). A weak point is the fact that one needs a certain level of knowledge in C. On the other hand, if one could have an application that reads XML gauge files and, for example, translates those to C gauge files that can be automatically compliled into .gau or .dll format by the application itself, would be a great advantage for XML-only developers.Personally, I've started diggin into the XML->C interaction and have built my own .dll, using my more-than-basic knowledge of C++ classes and functions. And I'm pretty happy with the results :-)>+ possibility to have a user friendly code interpreter, using>basic or pascal because XML for elements this is nice, but>look at the GPS (default) XML code and imagine this code just>in infix notation like Basic...Yeah, the dreaded GPS code...I was very scared when tried to understand for first time what all that messy (to me) group of lines meaned. But that was long time ago :-)Tom

[Varmint007 2]

I'm also intrigued by this idea JeanLuc. I think it could certainly offer advantages unavailable in XML-only gauges.Like Tom, I'm a firm believer in the strengths and performance of XML gauges. These are commonly dismissed as being useful only for rudimentary gauges, and I strongly disagree with that. I probably have at least as much experience with them as anyone else, having used them since introduction in FS2002.With a little bit more flexibility in terms of C-->XML interaction (perhaps the ability to bypass C++ altogether for the novice) and 'compile' into .gau or .dll, I think it would be a far more attractive and flexible solution than conforming to the new bloated ACES syntax and converting to .spb. At least in terms of security.It may even be possible to extend the "real" XML syntax this way, thereby providing a means to perform GDI functions from XML scripts. What's lacking in XML now could be boosted/augmented into something resembling a robust graphics set. For example defining pen styles for polylines, or adding the ability to define start and end points dynamically.Anyway, I think it's a great idea, with a great number of possibilities...--Jon