>Hi Al,
>
>>
https://www.theregister.co.uk/2018/01/09/meltdown_patch_anti_malware_conflict/>
>>The second link, especially, may be of interest to you. If your bundler/virtualizer makes any "naughty" system calls it might be affected by MS's Meltdown/Spectre >updates. I suspect some of these have been baked into 1803, since it's the first major "feature update" since Meltdown/Spectre were disclosed in January this year.
>
>You possibly nailed it!
>
>I suspect what this is all about. Yep the bundler - the defunct molebox does use tricks. Yep the chances that this may be conflicting with the hardening of the Windows OS:-(
>
Was my 1st suspect as well, but refrained from voicing since I had not used/tested it...
>I have got in contact with the companies (and individuals) who still sell this kind of stuff - enigma and boxedapp. They may have a clue. And possibly a solution. The bad new is that we have to get back to more traditionnal solutions.
>
>Alternatively:
>1) an MSI-based installer,
>2) a "Side by Side Manifest" based solution,
>3) other kinds of virtualization techniques...
>
>I do not know whether solution 2) ie "registrationless COM manifest files" are a decent workable solution for VFP executable. I currently embed a relatively manifest in the VFP executable.
>
>Has anyone here tested this?
>
>
http://www.manifestmaker.com/>
>I'd be glad to hear. I'll run a series test soon. This 1803-version WIN is making it a urgent and critical issue since our app does not deploy properly anymore. Not even with an MSI, The lastest we have is pre-2010!
My gut diddles between a version of 3) with
docker-like concepts and a clear distinction between local data and "executables" like exe, dll, fll, app, prg, report data and so on
or
trying to see if the specific use case can be solved without COM. Piping into other process in the long run easier to manage, albeit with heavier Marshalling/Process border cost.
If some version of 2) indeed IS a a better band-aid, that would be great. My fear is that it might turn into band-aiding the band-aid that is COM+registry ;-)
Our problems are mosty solved by cloning VM's, but as that is not a typical depoyment strategy I am a bit suspicious about my current surroundings tainting my posts ;-)
