Re: wine overstepping the mark?

[cdr]

[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

[cdr]

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: hello world

[cdr]

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

WinelibVersion() [was: bit-blit ops]

[cdr]

 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: WinelibVersion() [was: bit-blit ops]

[cdr]

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

Re: WinelibVersion() [was: bit-blit ops]

[cdr]

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

hello world

[cdr]

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

Re: hello world

[cdr]

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

Re: hello world

[cdr]

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

bit-blit ops

[cdr]

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