Hi Gianni, A quick search learns dat read-only files on NTFS file systems should indeed not be vulnarable to Cryptolocker. Unifacewise, from the top of my head I'd say: .ASN files are not written to .INI files, probably IDF writes to some during use (?) Uniface likes to be able to write to log and transcript files (if defined that way in ASN) Uniface debugger likes to write into UDBG.cnf So for run-time environment you will get far in making everything read-only, for the development environment probably not. One other thing not to overlook: your Uniface application itself (if programmed that way) could do all kinds of file dumps, even write into sections of any Windows .INI file through a signature and the Windows API. You could consider a "\\Workdir" sub directory as part of your Uniface app tree. Shortcuts would have the path to the "\\Workdir" sub directory as value for the "Start in" directory. Only the Workdir subdirectory would be writeable and then gets the role of a "garbage collector" directory. It will also collect file types that are not properly redirected in your ASN files. I've used this kind of set up for year for production environments.  All the best, Arjen

Arjen van Vliet said ... You could consider a "\\Workdir" sub directory as part of your Uniface app tree. Shortcuts would have the path to the "\\Workdir" sub directory as value for the "Start in" directory. Only the Workdir subdirectory would be writeable and then gets the role of a "garbage collector" directory. It will also collect file types that are not properly redirected in your ASN files. I've used this kind of set up for year for production environments.  ...

Me too! I've always suggested that structure to ALL Ucustomer I had the chance to work with... My current case (I feel) has a degree of complexity (3 separate Uniface applications, one of them with a Java front-end, Tomcat as a separately installed product but used somehow from all Uapplications and from the Java one...) to be managed. Defining a clear separation line between readonly and readwrite for each application will require few more efforts and probably a few tricks ;-) Anyhow thanks for your input: I do not need to protect development environment but only deployment and I was forgetting the need (sometimes) to debug at enduser workplace. Gianni

Hello, just a quick info... we deploy our application like this: Everything is on a network share. I mean, there is the Uniface runtime with all necessary files (.ini, .asn, our own .dll files...), all (Uniface) resources (basically the whole resources directory), Oracle instant client and so on. And then, there is our own .exe file - kind of downloader or installer or launcher or whatever you call it. All that user needs to run is that simple .exe file (the launcher) and it does everything. The share is readonly for all users (except admin of course) and our launcher checks for new versions, modified .dll or anything. There is also a check for vcredist to be installed locally and so on. Then the Uniface runtime is copied to the local disk, resources are kept on network share. If there is a virus (it has already happened), then user has to get rid of it and then just run the launcher with the "new install" option, which removes everything from local disc and copies it again. Since the net share is read-only, it should not be infected by any virus. If admin gets virus then... OMG. :-) Nevertheless... with this approach it's very easy to run our application on any computer. Kind regards, Zdeněk Socha

Hi guys, first tries today with following configuration: A) a readwrite local directory where all new or temp files should be written B) a readonly share on a network disk where Uniface runtime as well as all Uniface application objects resides Using a non administrator domain account Uniface Application is starting (hurrah!) but: - executing some application functions is remaining locked for minutes (1-2...) before showing the form layout - in other application functions is remaining locked for minutes (1-2...) executing a retrieve When the application is remaining locked for minutes: - mouse cursor is in waiting mode - application screen is becoming sometimes white, sometimes dimmed The question is: what the Uniface application is waiting for such long time ??? ...but also: is it an application issue or a Uniface issue ??? ...and next: how can I solve it ??? Any hint or help is welcomed... :-) Gianni

gianni said ... Using a non administrator domain account Uniface Application is starting (hurrah!) but: - executing some application functions is remaining locked for minutes (1-2...) before showing the form layout - in other application functions is remaining locked for minutes (1-2...) executing a retrieve When the application is remaining locked for minutes: - mouse cursor is in waiting mode - application screen is becoming sometimes white, sometimes dimmed ... 

OK, nothing related to Uniface but a misconfigured database access was causing those issues... Next bunch of test tomorrow! Gianni