[Vm-dev] Add argvec and envec to sqVirtualMachine.[ch]? (was: FT2Plugin stops working with latest version)

Igor Stasenko siguctua at gmail.com
Wed Oct 5 20:03:01 UTC 2011


On 5 October 2011 21:10, David T. Lewis <lewis at 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 at gmail.com> wrote:
>> > On 5 October 2011 16:41, David T. Lewis <lewis at 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 at 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 at 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:
>> >>> >
>> >>> > 1) 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.
>> >>> >
>> >>> > 2) 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).
>> >>> >
>> >>> > 3) 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.
>



-- 
Best regards,
Igor Stasenko.


More information about the Vm-dev mailing list