On 5 October 2011 21:10, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 05:19:48PM +0200, Igor Stasenko wrote:
So, my proposal is to add TheArgC and TheArgV variables to exports table of system module, in same way as on windows it uses to expose stWindow variable:
void *os_exports[][3] = { ... {"","stWindow", &stWindow}, {"", "argc" , &theArgc } .... };
then any plugin could lookup for given symbol using ioLoadFunction() function, and if there is no such symbol, then ok.. it will answer null , fail the primitive etc etc.
So, there is no need to change an API, just need to add few entries to os_exports structure.
I have no objection at all, this sounds like a good idea to me :)
I need to ask though, is ioLoadFunction() the one that you added for module security (some time in the last year or so I think)? That function crashes on 64 bit, so we would need to sort that out (sorry I can't look at source right now).
No, this function was there for ages, and it is use by various plugins like bitblt for interoperability between plugins. I changed the module loading mechanism to prevent loading new modules once image invokes a special primitive - disableModuleLoading. But other than that, i didn't changed anything.
Dave
On 5 October 2011 17:13, Igor Stasenko siguctua@gmail.com wrote:
On 5 October 2011 16:41, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Oct 05, 2011 at 04:15:20PM +0200, Igor Stasenko wrote:
On 5 October 2011 14:15, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote: > > On 4 October 2011 14:17, David T. Lewis lewis@mail.msen.com wrote: > > > > I think there was an issue on some of the Mac platforms that required > > a compiler flag to force the compiler to make global variables visible > > (for the environment vector, etc). Is that the problem here? I do not > > have a Mac, but I'll try to help figure this out if I can. > > > > If i remember correctly, a Cocoa VM using different entry point for > main() function. > or have some other differencies, so you cannot just pass argc, argv > around, but you have to prepare them. > > If you remember, i proposed to make an API for exposing these > variables, so then not only OSProcess could access them > but any other plugin, without need of hackish linking flags, which > lead to confusion and too compiler/linker specific.
Yes, I do remember this suggestion (although I can't find a pointer to it right now). I was mildly (not strongly) against it, but what do others think?
My opinion was based on:
- Setting a compiler flag to instruct it to make globals visible does
not seem hackish to me. After all, most of the compilers we use work like that anyway, and it does not seem to be hurting them.
- In order for the definitions to be visible for both a standard
interpreter VM and a Cog/stack VM, the definitions would need to be added to the existing VM_PROXY_MINOR 9 definitions. That amounts to changing the defined interface without incrementing the version number, which definitely does seem hackish to me (though probably harmless).
- The argument vector and environment vector are Unix constructs.
Adding platform specific things to the interpreter interface should be avoided. Again, this is harmless since all of the major platforms mimic Unix in this respect, but still ... all the world is not unix ;)
In any case, I do not have a strong opinion one way or the other, I'm just explaining my perspective on it.
Other opinions? Esteban, you are probably most directly affected by this, do you have a preference?
I have a strong opinion, that modules (and plugins) should access only those symbols, which are explicitly exported by module(s) they using, and not rely on something granted for free (implicitly visible via linker/compiler flags). Because if we don't care, then why do we need things like InterpreterProxy at all, if any plugin could just link directly to any VM function/variable in order to use it? Apparently, such approach violates the module encapsulation, because you no longer make sure that some symbols of your module is private and should not be accessed by others.
If no one else speaks up, then your strong opinion will outvote my weak opinion.
Also, may i ask, why OSProcess needs those vectors at all? Maybe a better solution would be to just avoid using them? I think, that it should be a responsibility of main module to expose those vectors, if it wants to, but not by a plugin. Because it again, violating the encapsulation principles.
OSProcess is full of stuff that I put in just because I felt like doing it. To be honest, I never expected it to be widely used by other people. And I certainly was not attempting to rise to any high standards of software purity ;) Having said that, I do think that it is important to avoid putting platform-dependent things into the VM and image. What I choose to put into my own plugin or my own project is my business (and the development of OSProcess was an example of that), but I do not think it is good for "features" in OSProcess to creep into the core system.
I understand the situation around plugin, Dave.
Yes, it is platform dependent. You can compile main module with different entry point (non POSIX), where you don't have access to argv/argc variables at all. For instance windows WinMain() function does not have them. But my point was more about who should take care about exposing those symbols, not about whether all platforms should support this API or not.
So, the point is, that since argc/argv stuff are coming from main module, then main module should care about exposing (or not) these symbols, not the third-party plugin.
Dave
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.