Re: wine overstepping the mark?
[EMAIL PROTECTED] wrote: Well that's why the sandbox is there... You are absolutely right. More and more Linux applications are becoming in this respect indistinguishable from Windows applications: they never even question their "right" to change your system behind your back. In their arrogance, they never even consider that one might want to restrict their ability to change things to that which belongs to a single user. A very unfortunate trend... cdr
Re: Test If Running Under Wine
Troy Rollo wrote: Also, if the application is testing for Wine, why not do a Winelib port? Single sorce to maintain, single binary to distribute. cdr
Re: Test If Running Under Wine
Craig macLeod wrote:
I am a developer of Win32 applications.
Same here...
How in our code do we differentiate between Wine runs and Windows runs?
Here is one possibility:
/* Get a non-0 to indicate we are running under Wine. */
iWine = (int)GetProcAddress(LoadLibrary("kernel32"),
"wine_get_unix_file_name");
The documentation discourages such tests saying we should fix Wine.
This is naive and far from practical. To me, it's self-evident that an
application will want know which run-time OS it's running under for many
reasons; it's completely inappropriate for the run-time OS supplier to
discourage it from doing so.
It is further my observation that Wine developers are (unfortunately)
not particularly interested in supporting application builders who
would like to make their applications run well under Wine; they
believe their system is primarily for the users who will want to run
an application that the application vendor would like to prevent from
running under anything but MS Windows.
cdr
Re: WinelibVersion() [was: bit-blit ops]
Felix Nawothnig wrote: cdr wrote: much appreciated, cdr Now... would you tell us what the misbehaviour in Wine is your application suffers from? Since bitblt isn't exactly rocket science this one should be easy to fix... (no?) It is on my "todo" list. But you must understand our difference in perspective: You believe my end user should upgrade to new versions of wine where these things are fixed. I believe that if I tell my user: upgrade wine, or forget running my app, I'll be the looser. I will simply not say that to my user, period. Thus, I need to know *both* that I'm running under wine and under what mmdd release "stamp" (BTW, pls keep it that way: it sooo much better than a "version number"). cheers, cdr
Re: WinelibVersion() [was: bit-blit ops]
Dimi Paun wrote:
if you *really* want to do it:
-- at compile time:
#ifdef __WINE__
#endif
-- at runtime:
if( GetProcAddress(LoadLibrary("kernel32"), "wine_get_unix_file_name")
{
.
}
much appreciated, cdr
WinelibVersion() [was: bit-blit ops]
Andreas Mohr wrote: ... >>>I have a need to detect - from within my application - that >>>it is running under wine. What is the correct way - if any - >>>to perform such test? >> >>This is something that we strongly discourage. You can just >>add a simple hack for now in your code, while we try to fix it >>properly in Wine. If you describe the problem, we may be able >>to fix it fast enough for your purposes. > > Indeed, and we also have > http://www.winehq.org/site/docs/wine-faq/index#HOW-CAN-I-DETECT-WINE > for that. > (I assume the above was meant to read ...we also have [... need] for that...?) Indeed. With due respect for wine developers and their excellent work, this may be worth reconsidering. Wine used to be almost exclusively for end users who had win32 applications (binaries), and wanted to run them under Linux, not only without any help, bu almost "againt the will" of the developers of those applications. I am, on the other hand, a different animal (and, looking around me, I notice my part of the zoo expanding...): a developer who would *like to help* my end user to run those applications under Linux. However, I can not possibly justify a complete re-write. Since wine is (and will remain forever) less than "100% windoze" (we can argue the numbers, but not the principle) the more I can be given a "helping hand" to deal with those residual differences, the more I'll be able to make my Win32 apps available to Linux users. (int WinelibVersion(); that returns nn - Please, please...) cdr
Re: hello world
Dimi Paun wrote: They are true Linux binaries (ELF format) but they need a bit of setup (for Windows compat) _before_ they start. Am I correct in assuming (see above in thread) that in some previous wine version it *was* possible to produce stand-alone version? Any plans to make it possible (again)? Perhaps for limited win32 functionality (graphics/GUI event handling only, no device access, registry, etc.?) But yeah, running the Win32 (PE) executables instead is a true possibility, same speed, etc. But having a Winelib port allows you to better integrate with the Unix env, which may be what you want for a 'true' Linux app. Should one expect read/write access to memory-mapped files to be faster if it is native Linux? (I must say I am impressed by the fact that Win32 memory-mapped file access works as well under wine as it does). cdr
bit-blit ops
While testing my Win32 application under wine, I came to the conclusion that some bit-blit ops behave differently from when the same code is running under native Windowds. While the subject will be researched further, as a stop-gap measure I have a need to detect - from within my application - that it is running under wine. What is the correct way - if any - to perform such test? tia, crd
Re: hello world
Dimi Paun wrote: > That's fine it's supposed to do so. But it's also supposed to > create a 'type' executable too (a batch file really). This is where I was (obviously) confused, all I can say in my defence is that Winelib User's Guide in "Getting started" implies that: (... You are done! Now you can start the application as ./notepad2 ...) And there is no mention of script that runs ...so - so I was expecting self-contained Linux binary. > That's all fine. You should get type.exe.so (correct, we need that) > and a type executable that basically does > > wine type.exe.so > I take it that means all winelib-ported apps are NOT true linux binaries - but some half-breed between win32 binaries and Linux binaries? What is then the advantage of porting (using winelib) as opposed to running win32 binaries under wine? Thank you very much for your help. cedar
Re: hello world
Dimi Paun wrote:
From: "cdr" <[EMAIL PROTECTED]>
Mkefile generated by winemaker creates type.exe.so; where I
would expect either type.exe or simply type. What am I missing?
Is the Makefile using winegcc to compile the app?
If so, you should get 'type' as the executable.
Yes. ("type.c" is a simple program from Petzold's book).
pertinent (I believe) lines from Makefile are:
..
EXES = type.exe
..
type_exe_MODULE = type.exe
..
### Generic targets
all: $(SUBDIRS) $(DLLS:%=%.so) $(EXES:%=%.so)
...
$(type_exe_MODULE).so: $(type_exe_MODULE).dbg.o $(type_exe_OBJS)
$(CC) $(type_exe_LDFLAGS) -o $@ $(type_exe_OBJS)
$(type_exe_MODULE).dbg.o $(type_exe_LIBRARY_PATH) $(DEFLIB)
$(type_exe_DLLS:%=-l%) $(type_exe_LIBRARIES:%=-l%)
...
(as if winemaker assumes I am trying to buils a shared library?)
In any case, tahnk you very much for your help
cedar
hello world
I am at the first stages of setting up my winelib development, and am attempting to build a simple app (named "type"). Mkefile generated by winemaker creates type.exe.so; where I would expect either type.exe or simply type. What am I missing? tia, cedar
