wine-devel

wine-devel@winehq.org

10 participants
84460 discussions

Re: [QUARTZDRV] Preliminary support for native OS X graphics
by Pierre d'Herbemont 23 Aug '04

23 Aug '04

Mike, Having Native Graphics Driver for Mac OS X is important for Mac User, since a X11 Apps doesn't behaves like a "normal" Mac OS X App. For instance, there is no icon for it in the Dock, which is indeed important. Moreover I am not convinced about the x11drv speed on Mac OS X. I didn't investigate much here, but the DGA extensions seems to be capital, and I don't think we'll get DGA on Mac OS X due to its windowserver architecture. Any way it is exciting to have an other driver other than x11drv and ttydrv ;) Pierre

1 0

Re: [QUARTZDRV] Preliminary support for native OS X graphics
by Roderick Colenbrander 23 Aug '04

23 Aug '04

Quartz support is ofcourse great but without a patch it isn't very usefull ;) Roderick Colenbrander > This patch includes a partially graphics driver for OS X. Everything > except the basic window management functions of the user driver are > stubs. The patch depends on Pierre d'Herbemont's "Support for > disabling symbols import in WineBuild based on a prefix." > > Changelog: > Rib Rdb <ribrdb(a)gmail.com> > Add preliminary support for native graphics on Mac OS X. > -- Superg�nstige DSL-Tarife + WLAN-Router f�r 0,- EUR* Jetzt zu GMX wechseln und sparen http://www.gmx.net/de/go/dsl

3 3

MSTS installer - files inside setupenu.dll
by Frank Eising 23 Aug '04

23 Aug '04

I am trying to get the Train SImulator setup working. Last time I debugged it I found that the setup looks for jpeg images in a certain directory to set up the setup menu. They are not found, because those files are non-existent on the cdrom. They are inside setupenu.dll. Anyone knows what kind of thing needs to be implemented, in order to make files inside a dll accessable by wine? I could not find any errors in the debug messages referring to it. Frank -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. >From your mailbox to local or overseas cell phones. Powered by Outblaze

2 1

Re: Optimize Critical Section Functions
by Andreas Mohr 23 Aug '04

23 Aug '04

Hi, On Fri, Aug 20, 2004 at 04:50:36PM +0100, Robert Shearman wrote: > Index: wine/dlls/ntdll/critsection.c > =================================================================== > RCS file: /home/wine/wine/dlls/ntdll/critsection.c,v > retrieving revision 1.26 > diff -u -p -r1.26 critsection.c > --- wine/dlls/ntdll/critsection.c 17 Jun 2004 23:11:08 -0000 1.26 > +++ wine/dlls/ntdll/critsection.c 20 Aug 2004 15:46:18 -0000 > @@ -36,6 +36,14 @@ > WINE_DEFAULT_DEBUG_CHANNEL(ntdll); > WINE_DECLARE_DEBUG_CHANNEL(relay); > > +#ifdef __GNUC__ > +# define likely(x) __builtin_expect(!!(x), 1) > +# define unlikely(x) __builtin_expect(!!(x), 0) > +#else > +# define likely(x) !!(x) > +# define unlikely(x) !!(x) > +#endif > + Umm, this should go into a global header file, right? The theory being that it would be useful at many more performance critical Wine places... But I have to admit that I don't know which header file this should be... Andreas Mohr

5 5

Re: Take monospace fonts into account in default font selectionalgorithm.
by Huw D M Davies 23 Aug '04

23 Aug '04

On Sat, Aug 07, 2004 at 04:20:11PM +0100, Mike Hearn wrote: > @@ -1717,9 +1719,12 @@ > } > } > > + /* match on charset and style */ > if(!family) { > for(family = FontList; family; family = family->next) { > - if(csi.fs.fsCsb[0] & family->FirstFace->fs.fsCsb[0]) > + > + if((csi.fs.fsCsb[0] & family->FirstFace->fs.fsCsb[0]) && > + (family->FirstFace->fixed_width == (lf.lfPitchAndFamily & MONO_FONT ? TRUE : FALSE))) > if(family->FirstFace->scalable || can_use_bitmap) > break; > } This also wouldn't work as you expect. The way to create a fixed pitch font is to use FIXED_PITCH not MONO_FONT. Which app was setting this flag? Huw. -- Huw Davies huw(a)codeweavers.com

3 2

Beginnings of quartzdrv
by Rib Rdb 22 Aug '04

22 Aug '04

Attached is a very preliminary driver for native graphics on OS X. So far all it does is let you make windows. No events or drawing work yet (I was baffled by the GetDC function. It looked like the existing drivers only call windows functions, and I didn't see any way for setting the window's context.) To compile this requires a patch by Pierre d'Herbemont to deal with conflicting function names in windows and Carbon. He said he will send it here. Also, to get the windows to focus, you have to place the executable in an application bundle. I just took one I had sitting around, copied the wine binary over the executable in the bundle and ran it from the commandline like so: /Users/ribrdb/Desktop/winemine.app/Contents/MacOS/CarbonTest winemine Things are getting busy with work, so I'm not sure when I'll have more time to work on this.

2 2

New Darwine Binary Released
by Sanjay Connare 22 Aug '04

22 Aug '04

Hey All, I am proud and happy to announce the release of a new binary labeled Darwine 20040820 DP. This binary is based upon the 20040813 wine release. The majority of changes for this release can be viewed: http://cvs.winehq.org/cvsweb/wine/ChangeLog It is being released as a DEVELOPER PREVIEW so USE AT YOUR OWN RISK! It is not yet suited for mass distribution or general user use. This release in addition to all of the fixes from the wine team includes many Mac OS X optimizations and fixes. It also includes WineHelper a native Mac OS X application that helps launch .exe's. It allows for .exe's to be double clicked in the finder like any other application and essentially bypasses the need to run wine via the command line. The Darwine libraries have been moved from their default installation location of /usr/local to a more Mac OS X friendly location /Library/Darwine. Applications and WineHelper are installed in /Applications/Darwine. This new binary also automatically uninstalls the previous binary if it is found to be installed. For uninstall to occur the user must enter an administrator's password. If the correct password is entered the uninstaller will return some errors however the old version of Darwine will be removed and the install of this new binary can commence by reopening the installer package. A new uninstaller is included with this release that simplifies the uninstall process thanks to the new location of libraries. The binary has been split into two releases one being this release and a soon to be released Darwine SDK. The Darwine SDK will contain the source for both wine and WineHelper, all of the header files, winegcc, winebuild tools and many examples and scripts that will allow open source apps to be compiled using these tools. Please report bugs to the darwine SourceForge Bug Tracking System, and to the darwine-devel mailing-list. Also any comments, questions or concerns can also be posted to the darwine-devel mailing-list. Enjoy this new release. Thanks, ~Sanjay Connare

2 1

Re: Wrong call convention for SHAllocShared & co?
by Ivan Leo Puoti 21 Aug '04

21 Aug '04

>Hence my confusion and my call for help. The solution that comes in mind is write a test program and find out. Ivan.

1 0

Re: Wrong call convention for SHAllocShared & co?
by Ivan Leo Puoti 21 Aug '04

21 Aug '04

> So who's right? The platform SDK that says this is a cdecl function or > Wine's headers? If the SDK is wrong and is diffrent from the windows implementation, then programs calling that function will have problems bacause of imcompatible headers between the ones used to build windows and the SDK ones used to build the program, no? Ivan.

2 1

Wrong call convention for SHAllocShared & co?
by Francois Gouget 21 Aug '04

21 Aug '04

In the platform SDK's shlobj.h I find: HANDLE _SHAllocShared(LPCVOID pvData, DWORD dwSize, DWORD dwDestinationProcessId); Notice the lack of a WINAPI and the leading underscore. So this would indicate a cdecl API. But in dlls/shell32/undocshell.h I see: HANDLE WINAPI SHAllocShared(LPVOID pv, ULONG cb, DWORD pid); This really looks like the same function, just without the underscore. Furthermore shell32.spec says: 520 stdcall SHAllocShared (long long long) So who's right? The platform SDK that says this is a cdecl function or Wine's headers? There's the same issue for SHFreeShared, SHLockShared and SHUnlockShared. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

1 1

Re: MS Visio 2000 not working with wine.
by Tom 21 Aug '04

21 Aug '04

James Courtier-Dutton wrote: > Tom wrote: > >> James Courtier-Dutton wrote: >> >>> Has anyone got MS Visio 2000 working with wine? >>> >>> James >>> >>> >>> >> >> Yes. >> >> Tom >> >> > > I am using the current cvs of wine. Without any Windows OS already > installed. > I attach a debug trace of trying to install Visio2000. > wine Visio2000.EXE > > Can anyone give me advice on how to diagnose this further? > > James > > > Hi James, Well it will install and run but your going to have to put some work into it :) I just installed it again in a clean .wine and this is what I did. 1) install dcom98 2) install native windows installer 3) install IE 6.0 4) remove conflicting dll's from IE 6 install that halts the Visio update. 5) install a couple native dlls so the installer will run 6) install visio 7) replace dlls that I removed from IE 6 install 8) tweak the config a little 9) run Visio Regards, Tom A proof shot that it works with wine :-)

1 0

Re: make CryptSetProviderEx update the provider Name and TypeName to registry
by Alexandre Julliard 21 Aug '04

21 Aug '04

James Hawkins <truiken(a)gmail.com> writes: >> Changelog >> * Call provider.dll's DllRegisterServer from CryptSetProviderEx to >> update the Name and TypeName values in the registry properly when >> setting the default provider It doesn't seem right to call DllRegisterServer from there, IMO it should only be called when the dll is installed. Do you have evidence that Windows does it this way? -- Alexandre Julliard julliard(a)winehq.org

2 2

MS Project 2000 not working in wine.
by James Courtier-Dutton 21 Aug '04

21 Aug '04

Has anyone got MS Project 2000 working in wine? James

2 1

MS Visio 2000 not working with wine.
by James Courtier-Dutton 21 Aug '04

21 Aug '04

Has anyone got MS Visio 2000 working with wine? James

2 1

Re: Added path settings to winecfg
by Marcelo Duarte 21 Aug '04

21 Aug '04

Jacek Caban escreveu: > But what about other languages, which nobody updates as you do? > I have one more question: where can I find this script? I see that > polish translation is far from complete and I thought I could work > aroun dit. > > Thanks, > Jacek Sorry for the delay. Atached is the patch to create a trans.sh in in wine/tools. To run in wine directory run tools/trans.sh and it creates tools/trans_html/index.html This is a modified version of the original patch that Vincent Beron send in January.

1 0

[Fwd: Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]]
by Mike Hearn 21 Aug '04

21 Aug '04

-------- Forwarded Message -------- From: Con Kolivas <kernel(a)kolivas.org> To: Mike Hearn <mike(a)navi.cx> Cc: ck(a)vds.kolivas.org Subject: Re: [ck] Re: Threading issues? [ck-request(a)vds.kolivas.org: ck Digest, Vol 3, Issue 16] Date: Sat, 21 Aug 2004 10:39:21 +1000 Mailer: Mozilla Thunderbird 0.7.1 (X11/20040626) Mike Hearn wrote: > On Tue, 17 Aug 2004 10:06:46 +0200, Andreas Mohr wrote: > >>Are we doing some big no-nos in the threading area here? >>(or maybe it's just done the way it is because we cannot do it a >>different, better way?) >> >>For the whole discussion, please see >>http://bhhdoa.org.au/pipermail/ck/2004-August/000428.html > > > Well, apparently we don't use sched_yield, so the problem must > lie somewhere else. Maybe Con can help us out here? Alexandre says he > doesn't know what the issue is either and somebody needs to investigate. I > guess we do need to concern ourselves over the details :) Interesting. Probably the most valuable information is that it seems to work fine if we artificially limit the threads to exactly the same timeslice _or_ we put them at such a low priority that they are forced to be guaranteed to round robin one task at a time. This is the way 2.4 used to work which is why with the new 2.6 schedulers which do far more out-of-order rescheduling some applications have a problem; particularly under load. I suspect it's actually the latter issue. Locking between threads should prevent that being a problem, though. You already mentioned that you dont use sched_yield() and I couldn't even begin to look at the wine code myself so perhaps you know something more. The other (useful?) bit of information is that one person solved his issue with this: >I had a similar problem with Cedega. I fixed it by editing the >Cedega/WineX config file and specifying that I wanted to use ALSA >instead of WineOSS, then disable mmap for ALSA. I'm not sure if that fixes all the problems but perhaps that helps. I'm interested in getting this resolved so please keep me informed. Cheers, Con P.S. Sorry I had trouble posting to your newsgroup.

1 0

Re: Limit number of DirectDrawClipper_SetClipList FIXMEs
by Stefan Leichter 21 Aug '04

21 Aug '04

Am Freitag, 20. August 2004 18:37 schrieb Tobias Burnus: > + > HRESULT WINAPI Main_DirectDrawClipper_SetClipList( > - LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwSize > + LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwFlag > ) { > ICOM_THIS(IDirectDrawClipperImpl,iface); > - FIXME("(%p,%p,%ld),stub!\n",This,lprgn,pdwSize); > + static int warned = 0; > + if (warned++ < 10 && lprgn != NULL) Hello, for me this looks like if (0 < 10 && lprgn != NULL) what is the same like if (lprgn != NULL) I thing you meant something different Bye Stefan

3 3

Compile on AMD Opetron
by chall＠bcrl.stcloudstate.edu 21 Aug '04

21 Aug '04

I tried to compile wine-2004813 on a AMD Opetron this is what I found. ./configure No Problems found. make depend No Problems found. make **FAILS** chuck@sniper wine-20040813 $ make make[1]: Entering directory `/home/chuck/src/wine/wine-20040813/libs' make[2]: Entering directory `/home/chuck/src/wine/wine-20040813/libs/port' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o interlocked.o interlocked.c interlocked.c:248:3: #error You must implement the interlocked* functions for your CPU make[2]: *** [interlocked.o] Error 1 make[2]: Leaving directory `/home/chuck/src/wine/wine-20040813/libs/port' make[1]: *** [port] Error 2 make[1]: Leaving directory `/home/chuck/src/wine/wine-20040813/libs' make: *** [libs] Error 2 chuck@sniper wine-20040813 $ After looking at the file libs/port/interlocked.c I noticed that there are special instructions for the UltraSPARC proc. Since I do not read or know asm, I looked at the #include for for Solaris (/usr/include/synch.h). pulled from solaris 9 on sparc. (/usr/include/synch.h) /* * synch.h: * definitions needed to use the thread synchronization interface */ I then looked through a number of other include files and noticed that all this seems to be is a control for threads. Under linux on the AMD Opetron could you not use the pthreads.h #include file? If you need access to a AMD Opetron box I can setup remote access (via SSH) so you can test the code, or I can try the patches (if any) sent. Have Fun! Chuck Hall

2 1

Suggestion for wine-user
by Geoffrey Leach 20 Aug '04

20 Aug '04

Perhaps some "worked examples"? It would be helpful to be able to have a set of examples that would illustrate the basic features of Wine. For example: o A "Hello World" .exe that used only the .dll files in the dist. o A script that executed a Windoze app that required only minimal configuration -- for example, just the mount point used for C: o A script that executed a (local) .exe that had its own (local) .dll files (both on the Unix side) Kudos to whoever put together the rpm. Regards.

1 0

Document an API difference
by Shachar Shemesh 20 Aug '04

20 Aug '04

Hi list, I'm documenting a probable API result difference between Wine and Windows. At the moment, this is no longer a problem as far as I'm concerned, so there is no point for me to write regression tests and fix it, but this may be stopping someone else. It seems that if you call "select" with a FD set that holds the same file descriptor more than once, Wine's and Window's responses are different. Under windows, you get a statement saying that only one FD is active. Under Wine, you get as many as the number of times the repeating FD is in the set. Like I said, this does not affect, as far as I know, any program, so I'm not sure we need to fix it. I just wanted the list's archive to have a mention of this issue. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

1 0

Re: Backtrace Dumps
by Alexandre Julliard 20 Aug '04

20 Aug '04

Robert Shearman <rob(a)codeweavers.com> writes: > I propose the addition of this new debug tool that will allow > developers to output backtraces to the console, without having to > interact with a debugger. It can give a useful indication of how > functions are being called in situations where a break point is not > appropriate. I think it's better to let the debugger take care of that. If you don't want a real breakpoint you could define a custom exception to tell winedbg to just dump the backtrace and continue. -- Alexandre Julliard julliard(a)winehq.org

7 13

Re: Optimization for FindFile* (resend)
by Alexandre Julliard 20 Aug '04

20 Aug '04

Robert Shearman <rob(a)codeweavers.com> writes: > Changelog: > Handle case of mask containing no wildcards so that it is possible to > avoid searching through hundreds of directory entries. I'm afraid this doesn't work, you need to take the file position in the directory into account, and also update it properly (which will probably defeat the optimization). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Move include/async.h to include/wine/async.h
by Alexandre Julliard 20 Aug '04

20 Aug '04

Robert Shearman <rob(a)codeweavers.com> writes: > Changelog: > Move include/async.h to include/wine/async.h Actually that file should be removed, we don't want to share internal data structures like that. It will require some restructuring of the async I/O support though. -- Alexandre Julliard julliard(a)winehq.org

1 0

Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]
by Andreas Mohr 20 Aug '04

20 Aug '04

Hi all, this is a nice little posting from the Con Kolivas Linux interactivity patches list. Note that it is about Cedega, not Wine, but it might easily affect Wine, too. Are we doing some big no-nos in the threading area here? (or maybe it's just done the way it is because we cannot do it a different, better way?) For the whole discussion, please see http://bhhdoa.org.au/pipermail/ck/2004-August/000428.html Andreas Mohr ----- Forwarded message from ck-request(a)vds.kolivas.org ----- Message: 12 Date: Mon, 16 Aug 2004 21:31:59 +1000 From: Con Kolivas <kernel(a)kolivas.org> Subject: Re: [ck] 2.6.8.1-ck1, cedega-cvs, ALSA sound (choppy) To: greblus(a)poczta.onet.pl Cc: ck(a)vds.kolivas.org Message-ID: <41209B2F.4030207(a)kolivas.org> Content-Type: text/plain; charset="us-ascii" Wiktor Grebla wrote: > On Mon, Aug 16, 2004 at 08:16:08PM +1000, Con Kolivas wrote: > > >>It wont be a preempt threshold problem. >>See if it's a priority issue on the part of wine*. Be absolutely certain >>that wineserver, wine and the game are all run the _same_ priority and >>not a better priority than X. Send me the output of 'top -b -n 1' during >>the sound being choppy. Then try running _all_ the wine things at nice >>+19. This is a simple sanity check to see where the problem lies. > > > It's in fact as you say, all parts of wine have different priorities, and > some of them are higher than X: > > greblus@greblus:~$ top -n 1 -b | grep wine > 1630 greblus 23 0 471m 230m 164m R 92.8 45.9 1:54.63 wine > 1666 greblus 20 0 471m 230m 164m S 2.0 45.9 0:01.64 wine > 1629 greblus 20 0 2400 1192 2176 S 0.0 0.2 0:00.00 winex > 1633 greblus 20 0 6864 5056 6756 S 0.0 1.0 0:01.10 wineserver > 1634 greblus 20 0 6864 5056 6756 S 0.0 1.0 0:00.15 wineserver > 1659 greblus 20 0 471m 230m 164m S 0.0 45.9 0:00.00 wine > 1660 greblus 21 0 471m 230m 164m S 0.0 45.9 0:00.00 wine > 1662 greblus 20 0 471m 230m 164m S 0.0 45.9 0:00.06 wine > 1663 greblus 33 0 471m 230m 164m R 0.0 45.9 0:00.41 wine > > greblus@greblus:~$ top -b -n 1 | grep X > 621 root 20 0 88092 18m 75m S 0.0 3.8 1:02.96 X > > After renicing all of them there is no problem with choppy sound in all of time > wasting programs I've on my disk :>, and overall (subjective) performance is > better of course. > > Full output of top -b -n 1 is here: > http://unixforge.org/~greblus/ck/top_-b_-n_1.txt > > Kindest Regards, > W. Thanks for details. You do not have different nice levels; that is PRI that is different, which is the "dynamic" priority that constantly changes by the scheduler. It is as I suspected, though - if you renice everything +19 and the problem goes away it is bad programming on the wine developers' part that use what's called sched_yield instead of proper locking between their threads. Don't concern yourself over the details, but at least you have a simple workaround... sigh Cheers, Con

2 1

Re: Different X Displays and Wine
by Eric Frias 20 Aug '04

20 Aug '04

Alexandre Julliard (julliard_at_winehq.org) wrote:> We don't support having the same user run from different displays at> the same time. I don't think that's a common setup at all. It probably is not a common setup, but Boaz isn't the only person to have been bitten by this. It has happened both to us and to people who use our software. In our development environment, we usually use one or two common user accounts to do all development and testing in. I know this isn't ideal, but I don't have any power to change this. Anyway, with this setup, it is very easy to have two people developing or testing from the same account but displaying on separate machines. Right now we have been doing what was suggested earlier -- we have a script to launch our application and this script creates a .wine-$DISPLAY directory and points WINEPREFIX to that directory. This works well enough for now. It's inconvenient that the config file and registry aren't shared, so doing things like changing printer settings is a bit of a chore, but this hasn't bothered us too much yet. We're also making the assumption that not many users will be running this on multiple displays, so things will just work for most users and the few that do try to run on multiple displays will at least be able to do it. I'm curious how much work would be involved in fixing this correctly. I've never looked at the wineserver code, so I don't know if this would just be a matter of adding another variable to a data structure that gets passed around to all of the windowing code, or if this would require major changes to the way wineserver works. If it's reasonably easy, I might be able to make the fix or lend some assistance; if it is a large amount of work, we'll probably be happy with the workaround we have. Eric

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel