Not better. megapup . Its a double sided sword if wine is detectable why bother fixing wine bugs. If wine is reliability detectable applications developers have a simple path to exclude wine. Reason why we have to reserve the right to move any internal part as we see fit so in case of someone excluding wine we can counter. If wine is reliability detectable this can be used by virus writers to attack host OS. Problem is for support wine would have to expose wine version and host OS reason some bugs are particular to like Mac OS or Linux or BSD... Once you know the host OS you can code to syscall the hosting OS and attack it. Downside of giving it up is cross platform viruses become simpler. Downside out weights the good. You would have to give a really good reason why we have to. Giving developers a free pass does not help wine develop. Applications builder are free to ship custom versions of wine if required. LGPL license was chosen to allow this. If you are looking at wine as a free path out of having to develop natively for other platforms it is not megapup. There are two major solutions to your problems megapup. 1) Wine is designed to assist in cross porting of applications to build native programs as well. So if your program is compatible with winegcc and other tools when in build due to header flags wine is detectable. Secondary advantage is that you can take advantage of native paths for load heavy parts. Source level wine is simply detected. Making like program.exe.so binaries allows you the detection you are talking about since program.exe.so does not work with windows but works with wine also these files are platform Dependant ie Linux Mac OS BSD... So providing the required split. A path was already provided basically just required binary for windows and binaries for different platforms. 2) What would be wrong asking user if they are running in wine in the installer or providing a option in application to enable defective work rounds megapup. Thinking defect work around might have usage on future version of windows or clones like reactos. Using a controllable defect correction system would be the preferred method since wine developers still could use your program in bug testing by not enabling the work arounds. There is more than 1 path. To us we have provided enough paths detection reduces the usefulness of your program to us for bug testing. With wine where defects can disappear or be dependent on a particular video card driver or bit of software. Hard coding the defect handling should be last option because who to say in every case the correction you do in your code will not be cased by something you overlooked your end? megapup you could end up harming your uses with the solid detection. If there are good advantages it would be done.
