[PATCH v3 4/5] vbscript: Implement separate script dispatch objects for each named item.

Jacek Caban jacek at codeweavers.com
Thu Feb 6 11:42:20 CST 2020


On 06.02.2020 16:55, Gabriel Ivăncescu wrote:
> Hi Jacek,
>
> On 05/02/2020 22:54, Jacek Caban wrote:
>> Hi Gabriel,
>>
>> On 05.02.2020 18:38, Gabriel Ivăncescu wrote:
>>> Sorry for the noise, but another idea just dawned on me.
>>>
>>> What if we ref count the named_item_t itself, and store it from 
>>> vbscode_t instead. Then, we set the item->script_obj to NULL when it 
>>> has to be recreated (for persistent code). This shouldn't affect 
>>> external users that hold ScriptDisp, since it's only referenced from 
>>> vbscode_t.
>>>
>>> Of course we still unlink the named item from the list when script 
>>> is uninitialized, since that's what tests show.
>>>
>>> This approach should, I think, fix all corner cases, even with 
>>> multiple script dispatches referring to same named item.
>>>
>>> Thoughts?
>>>
>>
>> Shouldn't we just ignore SCRIPTTEXT_ISPERSISTENT flag when it's 
>> executed in context of named item? Your tests seem to indicate that 
>> such code does not survive releasing script. Is there any way they 
>> could affect a reinitialized script engine?
>>
>>
>> Thanks,
>>
>> Jacek
>>
>>
>
> So, I've added a lot more tests as suggested (using arrays/loops to 
> make it easier to extend), which revealed some interesting quirks that 
> I'll fix.
>
> Now, referring to this part: it seems the code is indeed persistent, 
> so we can't clear the flag, even though it's not "accessible". Hence 
> why it probably sent the OnEnterScript/OnLeaveScript in the first 
> place. With my refcounting named_item_t idea, this should be done 
> without special cases for those callbacks and actually re-execute it 
> properly.
>
> I used a hacky test to verify that the script with persistent "code 
> context" does get re-executed even with a dangling context -- I used a 
> busy loop like the following:
>
> w = DateAdd("s", 5, Now())
> Do Until (Now() > w)
> Loop
>
> And printed a trace() when script was uninitialized. It then waited 
> another 5 seconds when it was restarted, proving that the dangling 
> context code was executed again.
>
> Now, I know that sort of hack is unacceptable for a wine test. Do you 
> have some idea of how to test for side effects, or should I just let 
> it be? (I can't use visibleItem because it dies when script is 
> uninitialized, and even if you re-add it Windows will fail when 
> restarting the script).
>
> After all, the named_item_t refcounting code will still fix the 
> OnEnterScript/OnLeaveScript tests, so technically we do have a minor 
> test for it. Will that be enough? 


You could probably just use "testCall" there as a test script. Before 
reinitializing script, you can make sure that it's exposed by a new 
named item in in global scope and use 
SET_EXPECT(testCall)/CHECK_CALLED(testCall).


And for ref-counting named items, it could also use a bit more testing. 
My guess would be that we should store named item string (not reference) 
inside vbscode_t and lookup named items when the code is actually 
executed. It means that if host adds a new named item with the same name 
before reinitializing engine, the new named item will be used. 
Experimenting could show if that guess is right.


Thanks,

Jacek




More information about the wine-devel mailing list