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

[David T. Lewis]

On Fri, Oct 07, 2011 at 10:53:51AM +0200, Igor Stasenko wrote:
>  
> On 7 October 2011 01:39, David T. Lewis <lewis at mail.msen.com> wrote:
> >
> > On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote:
> >>
> >> On 6 October 2011 14:11, 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.
> >> >
> >> > To check my understanding, do you mean #ioLoadFunction:From: as implemented
> >> > in vm/sqNamedPrims.c, so the idea would be to treat the main VM as a module,
> >> > and load functions that answer the argvec and envvec from that module?
> >> >
> >>
> >> Right. It is already treated as a module, so it is not new.
> >
> > Thanks, I understand now.
> >
> > I'll try this with OSPP when I get a chance. Meanwhile, if you want
> > to take the lead on this issue to get the exported functions added
> > to platforms code, that would be good.
> >
> > I need to ensure that OSPP runs on trunk as well as oscog branches,
> > which means that updates to all those branches would be best. But
> > I suspect it may be possible to adopt a strategy of loading with
> > ioLoadFunction, and if this fails, try a direct reference to the
> > global variable (though I don't know if Carbon will allow this?).
> >
> 
> 
> Why? Why keeping workarounds?

Because for OSProcessPlugin I choose to maintain a certain level of
backward compatibity and support for as many different VM projects
as possible.

> You can introduce this logic right now in OSPP, without waiting
> updates to VM sources,
> since there are no any requirements to change VM code to be compatible.
> If those symbols are not exported by VM module, then plugin should
> behave as if platform have no support for this functionality,
> which is pretty fair (as you already told - some platforms/build
> configurations could simply not provide it). Its fine.

I will give it a try as soon as I have a chance (but I am traveling,
so maybe not this weekend).

> You fail primitive etc, and it is perfectly ok as to me.
> As soon as newer VMs will start exporting those symbols, an updated
> OSPP will be available to provide corresponding functionality.

It might be OK with you, but it is *not* OK with me.

> 
> Does that makes sense?

Yes, and thanks very much for your patience in explaining the export
mechanism (sorry I was so dense before!).

Thanks,
Dave