April 2003 - Wine-Devel - list.winehq.org

Re: New plans for wintab work.

by Aric Stewart

Hi Rob, Sorry for the delay before. I took friday off and have has a busy weekend. > > If Aric's pach is considered ready to go into CVS, then I can > start working on this in the following areas: > Alexandre makes this call :) > Painter support. > I beleive there are some problems getting Painter to work with > wintab. > This is my priority. This would be awesome. I banged my head against it for a while before moving on, where I am. It looks like it has to do with timing for the button messages and the information in the tablet packets. Under windows we receive a WM_LBUTTONDOWN message significantly before we seen any normal pressure or value in the pkButton field of the packet. Similarly the button up come right when the pressure and pkButton field are cleared. However under X, we get normal pressure until the threshold value before generating the Button event. additionally the button up can occurs while normal pressure is still around. I think this is confusing Painter because it gets caught inside of a IsButtonDown function and often gets very confused if the button is down or not. > > Additional configuration for wintab. > Aric's wintab reqires no configuration. > It is only targeted at Intuos tablets. > > My implementation was to have a zero config default > for the intuos2 tablet, similar to Aric's. > Config could be provided where necessary to > modify how an intuos tablet is seen by wintab, > or to allow other tablet types to be used by wintab. > > I could merge this work into Aric's implementation. > This would require significant re-factoring of Aric's > data structs to match the more generic data structs I > implemented. I tried to keep the data structures as generic as possible. They are all taken directly from the wintab 1.1 api specification on the web. I tried the fill most of the structures as generically as possible based on information I can gleed from the drv_wacom.o implementation for XFree86-4 The areas where i had questions i did comparisons with the windows programs with the same intuos2 tablet i was working on under linux. So those areas may be a bit more specific. I am pretty sure that most any other wacom tablets would work. I do not know if anyone has tested any other wintab devices but I would be very curious how they would work. Sort of the biggest trick i had to play was with the cursor ID numbering. If you look at these faqs i wrote up for CrossOver Office 2.0 you can see. http://crossover.codeweavers.com/docs/office/html/troubleshooting.html#PHOT… I was tempted to make the cursor IDs a value in a config file but thought it would just be best to try to avoid having to do much work in the config file. > > I may not have too much time to do work for the next 3 weeks, > but I'd hope to make some progress on the painter side. > That would be great. I also hope that you find it works well for you and photoshop. Other areas that are "less than perfect" *) None of the manager functions are there. *) All contexts are basically CXO_SYSTEM contexts. this means that the applications always get the mouse moves and button events for the tablet. This is find for Photoshop and painter because they both want CXO_SYSTEM contexts. But under windows you can have contexts where the application does not get the mouse events for the tablet. only the tablet messages. *) nothing is implemented for relative mode packets. All the data is presented in absolute mode. *) a number of things are not implemented such as tangent pressure, and other axis that the intous tablet does not have. *) I am not particularly happy with the way that the packet data is communicated from the x11drv layer to the wintab32 layer. Also i think the way i handle the packet queues is sort of fast and sloppy. Sorry again for the lack of communication before, I look forward to the improvements you can make. thanks -aric

April 28, 2003

Re: slovene keyboard without dead keys

by Dmitry Timoshkov

"Rok Mandeljc" <rokmandeljc(a)hotmail.com> wrote: > Thanks for help, but that doesn't work for me. If I do Option "XkbLayout" > "us,si" my keyboard is properly detected, but dead keys (alt+something) are > screwed up both in wine and linux (in both us and si). That's a completely different problem and very likely caused by missing proper environment variables controlling locale needed by Wine. -- Dmitry.

April 27, 2003

Re: X11DRV_DIB_CreateDIBSection

by Ulrich Weigand

Robert Lunnon wrote: > Under Solaris I have a problem with this function.which appears to protect a > section of the DIB giving a portion of it no access at all and when the > application tries to blit from it later, a segfault results. That's how it is supposed to be. The segfault handler should then call the handler installed by the X11 driver (via VIRTUAL_HandleFault), which should mark the DIB as user-accessed, mark the DIB memory as readable, and return to the app. If this doesn't work correctly, there is most likely a problem with the sparc segfault handler not calling VIRTUAL_HandleFault properly (i.e. not called at all, called with incorrect fault address, ...). Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

April 27, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Francois Gouget

On Sun, 27 Apr 2003, Dimitrie O. Paun wrote: > On April 27, 2003 12:47 am, Francois Gouget wrote: > > > Only as far as commercial companies are concerned. Under the GPL > > license, anyone can fork QT. > > And you think this is any way acceptable? Bah, I don't really care. Maybe because I use neither Gnome nor KDE. I see your point but I can't help but think that it's a bit of a stretch to say Trolltech could become another monopoly when there is a GPL implementation available, which is why I said the above. > I am sorry, but an OS that puts commercial development at such a > tremendous disadvantage (that is, subject to the monopolistic whims of > one company) is not a platform. So all the portability issues you > listed don't even start to apply. Because KDE's license is bad it does not matter whether WIDE is portable or not? That does not make sense. Your telling people to ignore a fatal flaw in WIDE just because _one_ of the other frameworks has what you say is another fatal flaw. That's jumping out of the fire and into the pan. Now if you think WIDE is portable, tell us how. > > So you're saying Linux developpers should abandon Gnome/Gtk and KDE/QT > > and instead develop using Win32+OLE+COM? > > No! Unfortunately, KDE/QT is in a difficult situation due to the > licensing problem. It is the desktop of choice for most people, > I use it, but I can't see what we can do about it. So the situation will remain the same: we will haev KDE applications and WIDE applications and they will not be interoperable. I.e. it won't be possible to insert an Excel spreadsheet in a KWord document. > > I'm not criticizing, I'm trying > > to clarify because in one of your previous email I had the impression > > that you advocated development against a Win32-based Gtk API. > > Gtk is already ported to Win32. App wouldn't even know what Gdk backend > is used, they would be just the same. Does that include interoperability with OLE/COM/DCOM or just the look and feel integration? > They have a choice: Gtk/Gnome, wxWindows, Win32. There are a lot of > free apps (see the top SF downloads for examples) that use the Win32 > API, so it's not something new I'm suggesting? Do you think it's more > moral/ethical to treat these apps as second class citizens in Linux? I don't see the problem. Do you think it's more moral/ethical to treat open-source MacOS/X applications as second class citizens in Linux? What about DOS applications? OS/2 applications? Amiga applications? > > Yes it would be very cool. I am far from being an expert on OLE/DCOM but > > I have been told that it may be feasible. Probably a heck of a lot of > > work though. > > I'm not saying it would be easy. But given that Bonobo was so deeply > inspired by OLE, I'm hoping it can map easily onto an OLE backend, > and maybe that leads to an easier path to integration. I think we agree on most of the goals: we both want to integrate the Wine, Gnome and KDE environments. By 'integrate' I mean, integrate the menus and associations, automatically use the same look and feel, and make it possible to use object components of one in the other and reciprocally. I believe where we differ is on the method: * I think we should work on Wine to make that possible (though there may be some work to do in Gnome and KDE). * You think that it is mostly Gnome that must be modified to use the Wine APIs and you are ready to drop/ignore KDE. I believe you also proposed to replace Nautilus/Konqueror with Explorer, and to develop a new window manager. > > Other questions so I better understand: > > * are you proposing source-level compatibility or binary level > > compatibility? > > Both. We get both with Wine, we should be able to keep that. Of course binary compatibility will only work on the x86 platform. Porting applications to another platform will require recompiling them. This will put commercial applications based on a commercial framework such as MFC and Visual Basic at a big disadvantage. Is it fair to tell people that this is the way to go when it will restrict them to the x86 platform? I think not. Then you would push Gnome/Gtk as the framework of choice for WIDE. But for these developpers, what's the advantage of WIDE compared to the regular Gnome? It seems to me that it only risks to tempt them into using non-portable APIs. > > * how do you propose to handle the issue of drive letters? > > What we do in Wine is just fine. I'm only concerned with GUI apps, > and there I see drive letters as just shorthands to a bunch of > dirs. If you like that, go nuts. I see it as mainly a UI thing, > other than that we'd try to pass Unix paths around as much as > possible. You seem very concerned about look and feel. But drive letters are just as big an issue. You won't have a unified desktop unless this is handled uniformly. Or do you propose that Gnome applications too use drive letters? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

April 27, 2003

Re: Mac OS X Support (patch with diff -u)

by Marcus Meissner

On Sun, Apr 27, 2003 at 10:09:43PM +0200, Pierre d'Herbemont wrote: > Hi, > Here is a patch which mostly enables compilation on Mac OS X. The > support is not full as there is still some makefiles issues on which I > can't find a *clean* correction and a new issue I discovered in this > cvs version related to the libwine_port and the getopt function. > > Sorry for the -u option, I thought it was enabled by default :( The PPC assembly stuff appears correct to me :) Ciao, Marcus

April 27, 2003

Wine on cygwin

by Steven Edwards

It seems kernel and ntdll are not seperated properly as I can build ntdll.dll on cygwin now with no problems but when it gets to dlls/kernel it is failing with this error. If I include the ntdll files wine/memory/* wine/loaders/* and others in kernel32 then it will build. Thanks Steven dllwrap -k --def kernel32.spec.def -o kernel32.dll kernel.res.o ../../ole/ole2nl s.o change.o comm.o computername.o console.o debugger.o editline.o format_msg.o kernel_main.o lcformat.o locale.o stress.o string.o sync.o thunk.o time.o toolhe lp.o utthunk.o win87em.o windebug.o wowthunk.o kernel32.dll.dbg.o --entry _MAIN _KernelInit -L../../dlls -lntdll -L../../libs/wine -lwine -L../../libs/unicode -lwine_unicode -L../../libs/port -lwine_port -lm Warning: resolving _MAIN_KernelInit by linking to _MAIN_KernelInit(a)12 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups comm.o(.text+0x10f5): In function `EscapeCommFunction': /cygdrive/g/src/wine-dev/wine/dlls/kernel/comm.c:593: undefined reference to `_F ILE_GetUnixHandle' comm.o(.text+0x15b2): In function `PurgeComm': /cygdrive/g/src/wine-dev/wine/dlls/kernel/comm.c:710: undefined reference to `_F ILE_GetUnixHandle' comm.o(.text+0x1761): In function `ClearCommError': /cygdrive/g/src/wine-dev/wine/dlls/kernel/comm.c:751: undefined reference to `_F ILE_GetUnixHandle' comm.o(.text+0x1939): In function `SetupComm': /cygdrive/g/src/wine-dev/wine/dlls/kernel/comm.c:815: undefined reference to `_F ILE_GetUnixHandle' comm.o(.text+0x1e12): In function `SetCommState': /cygdrive/g/src/wine-dev/wine/dlls/kernel/comm.c:910: undefined reference to `_F ILE_GetUnixHandle' comm.o(.text+0x25fc):/cygdrive/g/src/wine-dev/wine/dlls/kernel/comm.c:1255: more undefined references to `_FILE_GetUnixHandle' follow computername.o(.text+0x5e4): In function `COMPUTERNAME_Init': /cygdrive/g/src/wine-dev/wine/dlls/kernel/computername.c:219: undefined referenc e to `_PROFILE_GetWineIniBool' computername.o(.text+0x161c): In function `SetComputerNameW': /cygdrive/g/src/wine-dev/wine/dlls/kernel/computername.c:542: undefined referenc e to `_PROFILE_GetWineIniBool' kernel_main.o(.text+0x86): In function `process_attach': /cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main.c:75: undefined reference to `_FILE_umask' kernel_main.o(.text+0x98):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main. c:82: undefined reference to `_RELAY_Init' kernel_main.o(.text+0xf3):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main. c:127: undefined reference to `_TASK_CreateMainTask' kernel_main.o(.text+0x13f):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:138: undefined reference to `_main_create_flags' kernel_main.o(.text+0x196):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:141: undefined reference to `_main_create_flags' kernel_main.o(.text+0x1bb):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:95: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x1d5): In function `process_attach': /cygdrive/g/src/wine-dev/wine/dlls/kernel/../../include/wine/library.h:186: unde fined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x1ef):/cygdrive/g/src/wine-dev/wine/dlls/kernel/../../inclu de/wine/library.h:187: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x219): In function `process_attach': /cygdrive/g/src/wine-dev/wine/dlls/kernel/../../include/wine/winbase16.h:402: un defined reference to `_TASK_InstallTHHook' kernel_main.o(.text+0x225): In function `process_attach': /cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main.c:110: undefined reference to `_DOSMEM_MapDosToLinear' kernel_main.o(.text+0x249):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:110: undefined reference to `_GLOBAL_CreateBlock' kernel_main.o(.text+0x260):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:110: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x26c):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:111: undefined reference to `_DOSMEM_MapDosToLinear' kernel_main.o(.text+0x290):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:111: undefined reference to `_GLOBAL_CreateBlock' kernel_main.o(.text+0x2a7):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:111: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x2b3):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:112: undefined reference to `_DOSMEM_MapDosToLinear' kernel_main.o(.text+0x2d7):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:112: undefined reference to `_GLOBAL_CreateBlock' kernel_main.o(.text+0x2ee):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:112: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x2fa):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:113: undefined reference to `_DOSMEM_MapDosToLinear' kernel_main.o(.text+0x31e):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:113: undefined reference to `_GLOBAL_CreateBlock' kernel_main.o(.text+0x335):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:113: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x341):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:114: undefined reference to `_DOSMEM_MapDosToLinear' kernel_main.o(.text+0x365):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:114: undefined reference to `_GLOBAL_CreateBlock' kernel_main.o(.text+0x37c):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:114: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x388):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:115: undefined reference to `_DOSMEM_MapDosToLinear' kernel_main.o(.text+0x3ac):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:115: undefined reference to `_GLOBAL_CreateBlock' kernel_main.o(.text+0x3c3):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:115: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x3ca):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:116: undefined reference to `_DOSMEM_0000H' kernel_main.o(.text+0x3de):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:116: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x3e5):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:117: undefined reference to `_DOSMEM_BiosSysSeg' kernel_main.o(.text+0x3f9):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:117: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x400):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:118: undefined reference to `_DOSMEM_BiosDataSeg' kernel_main.o(.text+0x414):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:118: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x41b):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:119: undefined reference to `_DOSMEM_BiosSysSeg' kernel_main.o(.text+0x42f):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:119: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x471): In function `MAIN_KernelInit': /cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main.c:160: undefined reference to `_WriteOutProfiles16(a)0' locale.o(.text+0x2792): In function `LOCALE_Init': /cygdrive/g/src/wine-dev/wine/dlls/kernel/locale.c:1012: undefined reference to `_CODEPAGE_Init' thunk.o(.text+0x4ab): In function `_loadthunk': /cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:164: undefined reference to `_ NE_GetOrdinal' thunk.o(.text+0x515): In function `_loadthunk': /cygdrive/g/src/wine-dev/wine/dlls/kernel/../../include/wine/winbase16.h:402: un defined reference to `_NE_GetEntryPointEx' thunk.o(.text+0x1c82): In function `IsPeFormat16': /cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1115: undefined reference to ` _OpenFile16(a)12' thunk.o(.text+0x1ca8):/cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1117: un defined reference to `__llseek16(a)12' thunk.o(.text+0x1cc2):/cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1118: un defined reference to `__lread16(a)12' thunk.o(.text+0x1d0b):/cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1120: un defined reference to `__llseek16(a)12' thunk.o(.text+0x1d28):/cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1121: un defined reference to `__lread16(a)12' thunk.o(.text+0x2531): In function `C16ThkSL': /cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1368: undefined reference to ` ___wine_call_from_16_thunk' thunk.o(.text+0x2729): In function `C16ThkSL01': /cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1425: undefined reference to ` ___wine_call_from_16_thunk' thunk.o(.text+0x2b8d): In function `THUNK_AllocLSThunklet': /cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1592: undefined reference to ` _TASK_GetPtr' thunk.o(.text+0x2c85): In function `THUNK_AllocSLThunklet': /cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1626: undefined reference to ` _TASK_GetPtr' thunk.o(.text+0x3341): In function `CBClientThunkSL': /cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1894: undefined reference to ` _CALL32_CBClient' thunk.o(.text+0x33b6): In function `CBClientThunkSLEx': /cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1910: undefined reference to ` _CALL32_CBClientEx' wowthunk.o(.text+0xc4): In function `K32WOWGetVDMPointer': /cygdrive/g/src/wine-dev/wine/dlls/kernel/wowthunk.c:92: undefined reference to `_DOSMEM_MapRealToLinear' wowthunk.o(.text+0x3c4): In function `K32WOWHandle32': /cygdrive/g/src/wine-dev/wine/dlls/kernel/wowthunk.c:238: undefined reference to `_TASK_GetPtr' wowthunk.o(.text+0x5b4): In function `K32WOWHandle16': /cygdrive/g/src/wine-dev/wine/dlls/kernel/wowthunk.c:279: undefined reference to `_THREAD_IdToTEB' wowthunk.o(.text+0x6ec): In function `GetVDMPointer32W16': /cygdrive/g/src/wine-dev/wine/dlls/kernel/wowthunk.c:341: undefined reference to `_GlobalHandle16(a)4' wowthunk.o(.text+0x6fa):/cygdrive/g/src/wine-dev/wine/dlls/kernel/wowthunk.c:341 : undefined reference to `_GlobalPageLock16(a)4' wowthunk.o(.text+0x7ac): In function `LoadLibraryEx32W16': /cygdrive/g/src/wine-dev/wine/dlls/kernel/wowthunk.c:373: undefined reference to `_DIR_SearchPath' wowthunk.o(.text+0x225): In function `K32WOWYield16': /cygdrive/g/src/wine-dev/wine/dlls/kernel/wowthunk.c:195: undefined reference to `_Yield16(a)0' wowthunk.o(.text+0x23e): In function `K32WOWDirectedYield16': /cygdrive/g/src/wine-dev/wine/dlls/kernel/wowthunk.c:208: undefined reference to `_DirectedYield16(a)4' collect2: ld returned 1 exit status dllwrap: gcc exited with status 1 make: *** [kernel32.dll] Error 1

April 27, 2003

Re: slovene keyboard without dead keys

by Rok Mandeljc

----- Original Message ----- From: "Dmitry Timoshkov" <dmitry(a)baikal.ru> To: "Rok Mandeljc" <rokmandeljc(a)hotmail.com> Cc: <wine-devel(a)winehq.com> Sent: Saturday, April 26, 2003 12:28 PM Subject: Re: slovene keyboard without dead keys > "Rok Mandeljc" <rokmandeljc(a)hotmail.com> wrote: > > > I have problems with XFree86 4.3 and wine's keyboard layout detection > > scheme. It seems that wine can't detect dead keys and use alt, therefore my > > previous slovene layout isn't detected anymore. This one loads perfectly, > > although alt-key combinations don't work. > > I'm strongly against fixing problems with new XFree86 4.3.0 this way and > polluting x11drv with lots of similar keyboard layouts. A way to solve > your problem is to use something like this in your XF86Config: > > Option "XkbLayout" "us,si" > Option "XkbOptions" "grp:ctrl_shift_toggle" > > I.e. explicitly add "us" layout as the first language group and use > Ctrl+Shift to switch between base and alternate keyboard layouts. > > -- > Dmitry. > > > > Thanks for help, but that doesn't work for me. If I do Option "XkbLayout" "us,si" my keyboard is properly detected, but dead keys (alt+something) are screwed up both in wine and linux (in both us and si).

April 27, 2003

New plans for wintab work.

by Robert North

Ok, Here are my plans for wintab work. If Aric's pach is considered ready to go into CVS, then I can start working on this in the following areas: Painter support. I beleive there are some problems getting Painter to work with wintab. This is my priority. Additional configuration for wintab. Aric's wintab reqires no configuration. It is only targeted at Intuos tablets. My implementation was to have a zero config default for the intuos2 tablet, similar to Aric's. Config could be provided where necessary to modify how an intuos tablet is seen by wintab, or to allow other tablet types to be used by wintab. I could merge this work into Aric's implementation. This would require significant re-factoring of Aric's data structs to match the more generic data structs I implemented. I may not have too much time to do work for the next 3 weeks, but I'd hope to make some progress on the painter side. Comments/questions welcome. -Rob.

April 27, 2003

Re: Mac OS X and Wine troubles

by Pierre d'Herbemont

On Saturday, April 26, 2003, at 11:24 PM, Vincent Béron wrote: > Le sam 26/04/2003 à 16:16, Pierre d'Herbemont a écrit : >> Hi, >> >> First of all I have a good news :) : Wine is able to build on Mac OS >> X. >> >> We decided not to follow WineHQ cvs version for early build, in order >> not to be so much disturbed by others wine development and not to >> produce bad patches, but don't worry ;) we are (of course!) planing to >> send patches, I hope they would be integrated... >> >> I had never use Wine before so sorry for the basic questions. >> I ran wineinstall, everything goes well until wineinstall attempts to >> launch regedit. Wine goes wrong, it tells me : >> >> Warning: no valid DOS drive found, check your configuration file. >> Warning: could not find wine config [Drive x] entry for current >> working >> directory /Users/steg/Documents/Programmation/wine; starting in >> windows >> directory. >> /Users/steg/Documents/Programmation/wine/miscemu/wine: cannot find >> './programs/regedit/regedit.exe.so' > > Does MacOSX sets $HOME and/or $PWD? > Yes it does... > Also, from when's your base CVS version? Alexandre commited a patch of > mine related to exactly this a few days ago. > We were using the version 20030219 of wine... (see : http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/darwine/wine/) You may have found what was wrong, thanks ;) I am going to send our modification to the wine cvs tree. >> >> For me the problem comes from somewhere in the reading of the file >> ~/.wine/config, which exists and is parsed, but maybe I missed >> something in wine configuration (like a register file or something)? >> Could someone tell we wether I am wrong or not? > > Actually, durin wineinstall, ~/.wine/config is not used. A temporary > config file is created instead. > >> >> Secondly I manage to copy a windows folder to the root '/' of my disk, >> so I can launch an app with the command "wine notepad.exe". > > You may have problems with this as Wine is not a CPU emulator, so it > won't know what to do with the binary code in notepad.exe. > Yeah, but in this case notepad.exe has been built for PowerPC, so it shouldn't be a problem... >> I added a >> basic Mach-O (Mac OS X binary file format) compatibility to libwine in >> order the file type to be recognized. But now I am getting error like: >> >> wine: could not load 'C:\windows\regedit.exe': dlcompat: dyld: wine >> Undefined symbols: >> _FormatMessageA >> _RegCloseKey >> _RegCreateKeyExA >> _RegDeleteKeyA >> _RegEnumKeyExA >> _RegEnumValueA >> _RegOpenKeyA >> _RegQueryInfoKeyA >> _RegSetValueExA >> >> I suppose that the problem comes from the fact that the dlls are not >> loaded before the notepad.exe, assuming that the problem is still >> related with the ~/.wine/config reading. Do I suppose right? > > Have you installed the Wine libs (dlls) so that wine (or the dynamic > linker) knows where to find them? > I let wineinstall do everything so I assume that they are installed (/usr/local/lib/wine)... Thanks a lot, Pierre

April 27, 2003

Re: cvs hangs

by Ferenc Wagner

Mike Hearn <mike(a)theoretic.com> writes: > Try altering the compression level used with -z, iirc > there is a bug in CVS (some versions) where it'll have the > symptoms you describe when using compression Thanks for the suggestion. Basically, it hangs for every values of -z except 0. Seems like my client has trouble with the new server when compression is enabled. I will upgrade some time or other. Feri.

April 27, 2003