Again presuming far too much andreaplanet if wine is sandbox by system security the Z:\ does not tell you go every where so any detection that path will fail. I was not talking about secuirty through obscurity as such. We provide a detect path we are able to limited so cannot remove it. If we find an attacker using a detect path we have to have the right to remove it we can limit the damage that can do. This is where the problem comes in with all the forms of detect so far. You are going to hook to something that we one day may remove. So then we get yelled at if we say do that. There is a really dirty way to detect wine and it is the most dependable by the way. Try to run .exe.so if it runs it wine or another emulator base off wine. If it don't run it not wine or the wrong platform type. You can catch this failure by the way. Again can be secuirty filtered against to stop it from functional operation. You could also allow the file to be removed if missing going on as if you are on windows. So meeting our requirements. This kind of support is not going to be removed because someone decides to abuse detecting wine. We already have a built in counter measure. dll overrides settings. Flip the default if dll is not listed as builtin don't allow it to be loaded as builtin. So detect would be dead as door nail if we ever had to kill it. Yet restore able by altering winecfg libs for the application. Basically at some point you many have to tell user how to enable the extras anyhow. So why not just be up front and ask them. Simpler by the way don't have to include .exe.so for linux bsd mac os solarias... Detecting wine is the hard path. This way is using nothing about the internals of wine. The complete idea that you have to add something to detect wine is wrong. If you are after a way wine users/developers cannot block if they choose to forget it. That is impossible. Basically you guys are thinking the incorrect ways. Test function is the way. Not like windows is going to add elf support any time soon. Gert If you want to call system native in the first place .dll.so and .exe.so are the recommend to do it. As we say function tests. If it functions you have wine if it don't you have windows. Gert wine always has overhead. Interfacing with native dialogs sound like a way to save a lot of coding hell. Until you wakeup. Native dialogs on Linux are basically incompatible with windows. http://wiki.winehq.org/WinePluginApi Yep inserting a windows gui addon into gtk or qt currently is impossible. So you will have to rebuild your full front end native anyhow to have it work. That is basically most of the way to building the full program. Then there are threading control issues and other evils. You are talking a major undertaking. It gets to the point bugger it port program to QT will be simpler. Also thinking upcoming is arm and mips based processors so a port to QT or Java will be worth it. Low end of market will own to arm/mips process running Ubuntu and other full distrubtions, android and Windows CE. Sorry wine don't run on arm without being wrapped in qemu and being as slow as hell. Really have to look carefully for why to go the path you want Gert. Long term for most programs using wine as cross platform interface is wrong answer. It would be nice to have pass through libs in wine for qt and gtk we don't because it will hurt like hell. Even simple things like a file handle don't match up. If someone wanted to provide wrappers for that they could.
