_vfp.ServerName_access

[Rick C. Hodgin]

Does anybody know how to add an access method to the _vfp.ServerName property?

I'm willing to go with a C-based FLL solution if required.

Thank you in advance!

--
Rick C. Hodgin

 

[Chris Miller]

First off, an access method is something you need to add on the class, not an already instantiated object.

And since _vfp is not a foxpro object, there's already the end of that story.

You can see _VFP is an OLE server for two reasons when you try to find out what class it would be, if it was a Foxpro object:
? _vfp.class gives "OLE error code 0x80020006: Unknown Name."

? COMPOBJ(_vfp,_vfp.[highlight #FCE94F]Application[/highlight]) gives .t. which hints at _vfp being visualfoxpro.[highlight #FCE94F]application[/highlight] with an application property that's self referential, just like so many Microsoft OLE automation servers are.

I think _vfp is visualfoxpro.application, even though the last two compobj yield .f.:

oVFP = CREATEOBJECT("visualfoxpro.application")
? COMPOBJ(_vfp,_vfp.Application)
? COMPOBJ(_vfp,oVFP)
? COMPOBJ(oVfp,_vfp)

Bindevent can bind to properties, but that just means assignments to a property trigger the call of a delegate method you specfiy with bindevent, not helpful to react when the property is read-accessed.

To add another thing you won't need to try at all: a This_Access method would allow reacting to access of any property or method or event by the member name passed in as parameter, but even if _vfp would have a this_access method you could bind to somehow, it's a mechanism only working for VFP objects, not OLE automation servers.

And last not least: _vfp.top/left effect the _screen position. Someone once teached me the connection, but don't expect there to be some loophole by which _vfp is part of or hosts a VFP form object, just because _screen.class actually is "Form".

Chriss

 

[Rick C. Hodgin]

I was hoping there was a class definition somewhere in the VFP source code that's been provided that I didn't know about, something that could be tweaked. I have a case where I want to wrap an existing application with a launcher, but when I do that it makes _vfp.ServerName point to the launcher, and not the actual app that's being launched. I wanted to be able to intercept all _vfp.ServerName calls, and apply some logic to have it return the proper app, not the launcher app.

Your knowledge and consideration of the various matters on here is always impressive to me, Chris. Thank you very much.

My workaround will be to name the launcher the app name, and the app name to something else. Hacky, but it will do for now.

--
Rick C. Hodgin

 

[Chris Miller]

Thanks, Rick, I'm surely using VFP longer than I've become active here.

Are you starting an EXE by updating application.exe, if necessary and eventually DO main.prg IN application.exe instead of RUN /N application.exe and QUIT from the launcher?
Because _vfp.Servername is not your only problem, you also influence SYS(16,nProgramlevel) and I think there are more issues like that if you make your launcher.exe the resident process that stays in memory instead of starting the actual EXE.

If your new launcher is based on what I recommended to overcome the problem of application.exe being pinned to start or taskbar and thus not checking for updates and even less so updating: The way to overcome this is with an embedded launcher part of the application EXE itself. It will check for own version vs server version with AGETFILEVERSION() of self and update share main executable, though whatever check for update you use should work fine here, too. If there's no need for an update, the application.exe continues. If there's a need I start a launcher, which can be an explicit separate EXE or even a batch file generated on the fly or coming from the central update share, and that finally starts the updated EXE with its included update check, and that should find itself to be the current version, but will again self-contain the essential check for an upcoming version.

So the only weak point of that self-contained update mechanism is that the update check can't be something that will only become known when the update exists It can only gradually change. Edit: Not true, I told one way is to have an updater in the server share, but you would depend on the base recipe loading or starting something from an already known server share.

If the EXE doesn't need a change but something other than the EXE has to change, then the version check still means putting the unchanged exe with changed version information to the share. You could make it another separate file to check for changes which only has that version check purpose, but then also make it a weak point of the update mechanism. The other thing that's obviously unfortunate when it has to change, is the update share. It's possible to keep the share name, though, even in case the server itself changes. And it's possible to find some central point that isn't a moving target and can be asked for the current configuration regarding update share, that info could come from a settled Database everyone accesses per DSN or from a SQL Server or ftp or whatever else is safe from modifications by a user or hacker.

I had some users that reverted to an older version of a software as it allowed to do a thing that later was restricted. I found ways to move the data so the old version could not work anymore, but you have both types of users that intentionally or unintentionally remove themselves from the update mechanisms, however they are done, even if it's embedded.

The reason there always is a security hole and exit route somewhere is simply because an EXE cannot modify itself, it relies on that being done from something outside and how can it trust the outside? For that matter a batch file generated by the EXE is a good choice as you'd need to dig very deep to overcome it and overriding the update source or anything else. So self-generated update batch file is giving a reliable basis against fraudulent updates or even downgrades. If the update is done, that batch file is obsolete and can be erased, for example, so there even is no long term hint on where to disrupt the update mechanism. And though you never know what may come, things related to upgrades of databases etc. could be included in the new application.EXE or to qualify being allowed to do the updates you could let them pass an authentication mechanism.

One simple example of such diverting from a usual scheme is, you could introduce an appliction.exe parameter that in short says to skip updates and work in the current version, for sake of settling arguments about bug or feature history, so add a backdoor to exempt you from the mechanism always updating to the latest version.

And since that's a backdoor it has to be secured. For example by passing in something that's not a constant, but changes in time like a one time password as used in online banking by some hardware token. Something you can both generate and verify to be generated in the current time slot. So even if that specific parameter value leaks to some power user or hacker that monitors directories for batch files to take copies of them, it's nothing that works permanently and it would need both decompiling of the generation and verification code of the one time password plus ideally - as per algorithm used - some secret that should be separate, but bound to only be visible to that EXE process.

And that and how an exe can even trust itself to be itself, is a topic on its own. Let me just give one pointer to that:

https://www.techtarget.com/searchwi...PowerShell-Secret-Management-and-Secret-Vault

Chriss