atrodo.org News Vote Rant Projects		atrodo.org dwin draak atrodo E-mail
	DWin Object RFC Sitting here, i began to think a little. Well, it's been a long time coming, but i have finally decided to write this one. Now, i no way does this mean that DWin is soon going to support Shared Application Procedures (SAP), because it probably won't because of the hardships i had with it last time. But, i do want to get the ideas out there and hopefully get some feedback from people that come by the site regularly before i bring the idea up to a larger crowd. Anyways, DWin is eventually going to need some sort of shared object format, and i need to know what the specs are going to be. I've got some ideas, and some ideas of what's NOT going to go into the spec. So consider this my Request For Comment for upcoming SAP modules. It's not in RFC format, but it's also not fleshed out yet. Please feel free to email me at atrodo@atrodo.org with questions/concerns about these ideas. So, to begin, i need to expain SAP modules a little more. DWin, in it's last incarnation (pre-Build 65) had a limited ablity to load programs that dynamically linked to DWin's core. I.e. If you just ran the program, it wouldn't run because it doesn't accually have the code to create a window, that was DWin's job. This is where DLib came in, it was a large chunk of code that basically acted as a way for a program to know the internals of DWin's core, but has no functionallity. Old School DWin had a bad SAP implementation, mostly because the compiler didn't support it, and all it was was exporting the internals of DWin. The next version of SAP will have to do better then the last. Various things, from the way it's layed out to the need for direct compiler support, will help to make SAP a useful (hopefully) standard. When the real Spec work needs to be started, i will do some research into existing relocatable standards (ie DLL, .so, BPL (Borland's DLL extensions), ELF, etc) to get a better idea of how to implement such items. But for now, i need to define some ideas for SAP so that in the future, we won't need to spend so much time on this. My various ideas include: Has to be internally used by the compiler. Has to support Objects nativly. I.E. You can load an entire object, not just it's functions. Has to have the option that a developer's module has code, header/unit information, debug code, or all of them, or simply one of them. Inheiratence has to be dealt with so that a deeply inheirated function (AkA Class.Create or such) does not take forever to be located. Multiple languages need to be benifited by it. It shouldn't just lock out all but Pascal code. Has to be Object Oriented, but should be able to allow a non-object oriented language to access it. IE, Pascal and C++ can take full advantage of the module in it's simplicity, but C can still run code inside the module. Has to have a header chunk that can tell name, object, object inheiratence, ABI, etc so the developers only need to "#include" or "use" the module and be able to get full advantage of it. Function discovery needs to be an option so as to keep the preformance level up. Has to have a great Versioning system. Unique names/numbers for objects, let the objects and programs agree on what version the object will with, multiple versions can be loaded at any one time and the program can find the version that it requires. That is all the ideas i have for now. As i think of more and as people mail more in, i'll keep adding to the list.
				~
Note: This is an archived website. I built this between 2000 and 2004 and in some small way I feel that it has defined how I view my online presence. Although it's been years since I've updated, I have decided to keep it in its original glory and preserve it instead of replacing it with a blank page. Enjoy this glimpse into my younger self.