August 2002 - Wine-Devel - list.winehq.org

Re: --dll buggy behaviour ?

by Sylvain Petreolle

works, thanks. (tested with Desktop property to have a seeable result ;)) > wcmd.exe should work. in fact, this should be inserted in the wine > config file which will populate dynamically the registry (writting > directly to the registry files won't work. > > for example, add this to ~/.wine/config to run shell32/shell as > native > by default > > [AppDefaults\\wcmd.exe\\DllOverrides] > "shell32"="n,b" > "shell"="n,b" > > (see documentation/samples/config for more details and examples) > > A+ ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Aug. 26, 2002

Re: --dll buggy behaviour ?

by Eric Pouech

Raul Dias a écrit : > > Oi, > > Why not? > > I was thinking that this would be a good way to add specific apps > overrides to the global registry (thru regapi). because this part of the registry (the HKLM\\Wine\\Wine\\Config) is never actually saved back at wine exit it's filled, at Wine startup, with the contents of the wine config file A+

Aug. 26, 2002

How do I grab the screen contents referred to by an hDC?

by Bill Medland

Can anyone tell me how I can do this; I am trying to debug a problem with user32.dll under the native NT comctl32.? When drawing a ListView --debugmsg +relay shows three consecutive calls; SetRect (&rect...) FillRect (00000b04,&rect,00000082 (/* I reckon that is GetStockObject(BLACK_BRUSH)*/) DrawIcon (00000b04,0x40,0x60,hicon,...) Now as it stands I get random rubbish in the background of the icons (in the region covered by the mask). If I insert a hack into DrawIcon so that it does a FillRect (b04,the rectangle, GetStockObject (WHITE_BRUSH)) then things work out OK. (Also, the code seems to draw the icon to four hDCs and I can do the same hack on the second hDC to get the same effect but not the third and fourth). Firstly I don't understand how it has a chance of working given that it fills the rectangle with a black brush. So what I want is a way of seeing what the contents of the rectangular region is at the exit from the FillRect and the entrance to the DrawIconEx, based on the hDC. (Something like "give me the pixels of the 32x32 rectangle at this location of this hDC") Also it seems to me that these two function calls are consecutive, so if anything is changing I guess it would be as a result of code within comctl32 itself. Is there any other way that control can come back into the Wine code between a relay exit and entrance? Bill

Aug. 26, 2002

Re: Wine Ma os X port

by Igor Izyumin

On Monday 26 August 2002 11:45 am, David Suarez wrote: > Im kinda new to Wine, and I hope to get into very much, however I had one > question which im sure everyone has heard alot of. Is there any way to run > WINE on mac OS X being that it is based on FreeBSD. I have played around > with the mac's and have gotten several linux programs to run, however i > haven't tried wine yet. I do no that os X comes with many development tools > that could possible be used for porting an app, but then again i am new at > this so im not sure. Any information on this would be greatly appreciated. The only way that wine would be able to run on OS X is if: a) OS X gets ported to x86 b) Wine includes an x86 emulator and gets nearly re-written. Both have about an equal chance of happening. Read the docs at winehq.com for more information. -- -- Igor

Aug. 26, 2002

Re: Add BiDi infrastructure

by Shachar Shemesh

Alexandre Julliard wrote: >What I'm saying is that it's not a good idea to start using fribidi, >create dependencies and problems for packagers, etc. if we know that >it's a wrong design and that we will need to replace it. > Ok, accepted. Not only by me, but also by Bidi's maintainers. I'm currently shifting my efforts to creating the required infrastructure in fribidi for supporting all of our current and future needs (UTF-16 included). Once that's in fribidi, I trust depending on it will not be considered a problem, right? > The truth is >that bidi is not really a priority feature (as shown by the number of >people interested in making it work), > Ouch :-(. Actually, there is a lot of interest in people wanting Wine to support Bidi (or at least, Hebrew). This can be seen from the comments on any of the many articles in recent press about Wine, Lindows etc. Sadly, this did not create a movement of developers, true (unless you count yours truely as a "movement"). > and so it doesn't really matter >if it works tomorrow or only in 3 months. What matters is to pick a >correct design so that if more people start to care they can build on >it, instead of having to throw it away and restart from scratch. > > Point taken and observed. I'll make sure fribidi has, at least, the final package dependancy (I don't know, yet, whether packagers will choose to package fribidi-utf16 in a different package), and I'll resubmit. I have, pretty much, a guarantee from Behdad that the required changes will be supported. Time to direct efforts torwards a better fribidi design. Shachar

Aug. 26, 2002

Re: Wine Ma os X port

by Andriy Palamarchuk

--- David Suarez <david(a)suave.2y.net> wrote: > Im kinda new to Wine, and I hope to get into very > much, however I had one question which im sure > everyone has heard alot of. Is there any way to run > WINE on mac OS X being that it is based on FreeBSD. > I have played around with the mac's and have gotten > several linux programs to run, however i haven't > tried wine yet. I do no that os X comes with many > development tools that could possible be used for > porting an app, but then again i am new at this so > im not sure. Any information on this would be > greatly appreciated. The problem is - OS X runs on PowerPC processors architecture, but Window programs are compiled for x86 processors. However, it is possible to port Winelib to OS X. For details see: http://bugs.winehq.com/show_bug.cgi?id=44 Andriy __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com

Aug. 26, 2002

Wine Ma os X port

by David Suarez

Im kinda new to Wine, and I hope to get into very much, however I had one question which im sure everyone has heard alot of. Is there any way to run WINE on mac OS X being that it is based on FreeBSD. I have played around with the mac's and have gotten several linux programs to run, however i haven't tried wine yet. I do no that os X comes with many development tools that could possible be used for porting an app, but then again i am new at this so im not sure. Any information on this would be greatly appreciated.

Aug. 26, 2002

RE: Problems compiling wine with Intel Compiler

by Patrik Stridvall

> On Mon, Aug 26, 2002 at 05:40:01PM +0200, Patrik Stridvall wrote: > > The Intel compiler like the Microsoft compiler probably > already supports > > __int{8,16,32,64}. > > > > This will have to be changed to > > > > #if !defined(_MSC_VER) && !defined(XXX) > > Or maybe a HAVE_xxx configure check? In general this is the way is should be done. However no rule without an exception. :-) Short explaination: In the header files it can't be done that way because the same header files must support multiple compilers and thus they can't have a shared config.h file.

Aug. 26, 2002

Re: Problems compiling wine with Intel Compiler

by Joerg Mayer

On Mon, Aug 26, 2002 at 05:40:01PM +0200, Patrik Stridvall wrote: > The Intel compiler like the Microsoft compiler probably already supports > __int{8,16,32,64}. > > This will have to be changed to > > #if !defined(_MSC_VER) && !defined(XXX) Or maybe a HAVE_xxx configure check? Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Aug. 26, 2002

RE: Problems compiling wine with Intel Compiler

by Patrik Stridvall

> I'm getting compiler errors when I try to compile wine with the Intel > C++ 6.0 Compiler. This works fine with the g++ compiler. > > $ icc -c tstwine.cpp -I/usr/include/wine > tstwine.cpp > /usr/include/wine/basetsd.h(27): error: invalid combination of type > specifiers > typedef char __int8; > ^ > > /usr/include/wine/basetsd.h(30): error: invalid combination of type > specifiers > typedef short __int16; > ^ > > /usr/include/wine/basetsd.h(33): error: invalid combination of type > specifiers > typedef int __int32; > ^ > > /usr/include/wine/basetsd.h(36): error: invalid combination of type > specifiers > typedef long long __int64; > ^ > > /usr/include/wine/basetsd.h(36): error: invalid combination of type > specifiers > typedef long long __int64; > ^ The Intel compiler like the Microsoft compiler probably already supports __int{8,16,32,64}. The typedef are protected by a #ifndef _MSC_VER This will have to be changed to #if !defined(_MSC_VER) && !defined(XXX) where XXX is some that indicate that the Intel compiler is used. Check the manual. > /usr/include/wine/winnt.h(59): catastrophic error: #error directive: > You need gcc >= 2.7 to build Wine on a 386 > # error You need gcc >= 2.7 to build Wine on a 386 > ^ > > compilation aborted for tstwine.cpp (code 4) > > It looks like the wine headers need a level of the gcc version for the > compiler, but since I'm not using gcc, there is no gcc version level > set. Presumably the Intel compiler like the Microsoft compiler already defined __cdecl and __stdcall. In that case similar to first problem above the line # elif defined(_MSC_VER) will have to be change to # elif defined(_MSC_VER) || defined(XXX) where XXX is the same as above. > Has anyone built wine with the Intel Compiler? If so, what was > done to get this to work? > > Is any work being done to allow the usage of the Intel > compiler with wine? Not that I know of.

Aug. 26, 2002