Reply to thread

Message: <blockquote data-quote="Luke" data-source="post: 422769" data-attributes="member: 602">Functional decorations is a big issue to watch out for. You don't notice it too much if you're always using the same compiler and libraries built with the same compiler.Essentially, at a machine-code level, the functions in the DLL and the code calling the DLL, need to agree on many things for it to work.This includes: what name-mangling is done (eg does an underscore get put on the front of the function name, or does the name get capitalized), how parameters are passed on the stack (left to right, or right to left), and who cleans up the parameters off the stack (the caller, or callee).Generally things default to an industry standard of _cdecl, until Microsoft threw out a typical "decommoditizing protocol" on the standard, so that you virtually have to wrap every export function with another Microsoft DLL using properly "_cdecl"ed functions, to get cross-compiler portability happening.Using C++ in DLLs is typically only any good when the same compiler uses the DLLs, as was used to create the DLLs. Just about every different C++ compiler does their own variation on name-mangling, which makes the function names in DLLs useless to any other compiler (or VB app).You can get away with exporting 'C' functions from your C++ work, if you decorate them properly.You can check out different compiler DLLs with utilities like Quickview, so see how different the name-mangling is.This sort of thing is possible if you carefully set all the right standards in place, and all the developers stick to them.In general, I'd have to agree that Java is, unfortunately, the best way to port code libraries around. You pay for that with speed and deployment issues. Suddenly, everyone needs to buy-in to the download and installation of a Java run-time on their machine. If you've noticed that PCGen requires you to occassionally update the Jave run-time you have from Sun, you start to appreciate that more standards need to be put in place for Java configuration management, that everyone has to adhere to. One person in your big chain of interconnected software can cause you to need a large download and update. I couldn't personally tell you if that would cause backwards-compatibility issues with other existing software, but I've certainly seen it where different versions of 3rd party material is used.I gather that a segment of the PCGen community find the Java run-time updates a pain, and that's just for a *single* app.I think that the SOAP/XML was perhaps the best portability solution mentioned so far. It is the single, genuinely portable way to pass information around, and call functions with parameters (web services). It's essentially is a "nice" layer on top of tcp/ip, with the benefit of working for those stuck behind firewalls.Whilst this sounds attractive in putting together a massive RPG utility, composed of different RPG functions spread across the web, this too has a large number of problems:- You have to be on-line to make it work.- All contributors need to have reliable servers constantly on-line, with decent develop and testing procedures that keep the services available.- You pretty much have to run a web server of some kind to make your service available.- There is a *big* issue with version control, where the service providers and all clients are talking the same data formats. This is much harder than the very slowly progressing D20 XML project, where it addresses the relatively simple task of simply defining the database content.- It's *very, very* slow, compared to binaries (EXEs, DLLs, SO). Just stop to think about calling a name generator service 20 times to generate an NPC party on the fly. That's just a *name*, with potentially classes, equipment, skills etc to follow. Though you could get single services to package large result sets independantly, that's not the spirit, or intent of capabilities.- I'd predict that SOAP/XML is pretty unfamiliar to most people who would otherwise like to get involved in such a project.In all, as a person reasonably experienced with managing and implementing medium to large size developments, I see so many pitfalls concerned with managing the whole process (from requirement specification, through to implementation on an agreed platform capable of delivering expectations, through to on-going configuration management), that I would predict a very hard (but perhaps fun!!) road for those embarking on it. Chances of success would be quite low, or at least, well under the expectations of those eagerly watching on and waiting for it.</blockquote>

Verification