wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

Re: test skeleton Re: StgIsStorageFile
by Ryan Cumming 16 Nov '02

16 Nov '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On November 15, 2002 18:06, Greg Turner wrote: > On Friday 15 November 2002 02:29 am, Ryan Cumming wrote: > > On a side note, I made a pretty nice testcase for this, but there > > seems to be no dlls/ole32/tests directory. > > Ask and ye shall receive. Cheers :) I'll get to work on porting my StgIsStorageFile testcase tommorow. - -Ryan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE91b9sLGMzRzbJfbQRAtUYAKCIbfexD39A/4raTAqrMylFuCb73gCdG4NP lDhlqa8vxpF17phsWS1mqcs= =ud+e -----END PGP SIGNATURE-----

1 0

Re: Stub implementation of CABINET.DLL
by Greg Turner 16 Nov '02

16 Nov '02

On Friday 15 November 2002 12:47 pm, Patrik Stridvall wrote: > Now that we have the permission to use cabextract > under the LGPL it would be useful to have stubs > for CABINET.DLL so intrested people can work > with implementing it with fewer "infrastructure" > problems. > > ---8<--- > > *** cabinet > > * configure.ac, > include/fci.h, > include/fdi.h, > dlls/Makefile.in, > dlls/cabinet/.cvsignore, > dlls/cabinet/Makefile.in, > dlls/cabinet/cabinet.spec, > dlls/cabinet/fci.c, > dlls/cabinet/fdi.c, > dlls/cabinet/main.c: > Added stub implementation of CABINET.DLL. Anyone working on this? If not I'd be glad to take it on, seems like it should be easy. -- gmt "War is an ugly thing, but not the ugliest of things; the decayed and degraded state of moral and patriotic feeling which thinks that nothing is worth war is much worse. A man who has nothing for which he is willing to fight; nothing he cares about more than his own personal safety; is a miserable creature who has no chance of being free, unless made and kept so by the exertions of better persons than himself." -- John Stuart Mill

1 0

Re: Fw: Re: Filesystem change notifications
by Jeff Smith 15 Nov '02

15 Nov '02

> >It's not that I am for adding everything inline. That's not a good idea. >Also, I think a Windows compatibility layer can be forgiven for having more >dependancies than a personal finance program. This holds especially true if >non-core windows functionality is only available if the external library is >available at runtime (i.e. - no fribidi install - no Hebrew support in >Wine. No CUPS installed - no printing available etc.). I'm not sure this >holds true to something which is a core Windows function. > > Shachar I totally agree. And although we don't want to fall into "dependency hell", one has to consider we are trying provide a layer of compatibilty for an OS that is known for the same. So I think selective dependencies, as Shachar mentions, are perfectly reasonable. I don't mind a dependecy on FAM, but I could be biased, as I already installed it for the associated KDE functionality. If inserted as a conditional dependency, the fallback position if it is not present is no worse than the current position. Just my two centi-dollars. -- Jeff S _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0

CreateWindow fails
by steve.lustbader＠philips.com 15 Nov '02

15 Nov '02

My app calls CreateWindow like this: WNDCLASSEX wcex; wcex.cbSize = sizeof(WNDCLASSEX); wcex.style = 0; wcex.lpfnWndProc = (WNDPROC)MyWndProc; wcex.cbClsExtra = 0; wcex.cbWndExtra = 0; wcex.hInstance = hInstance; // from argument to DllMain wcex.hIcon = NULL; wcex.hCursor = NULL; wcex.hbrBackground = NULL; wcex.lpszMenuName = NULL; wcex.lpszClassName = TEXT("foo"); wcex.hIconSm = NULL; RegisterClassEx(&wcex); g_hTarget = CreateWindow(TEXT("foo"), TEXT(""), WS_POPUP, 0, 0, 0, 0, NULL, NULL, NULL, NULL); ASSERT( NULL != g_hTarget ); It fails the final assertion in Wine but not in Windows. Any idea why CreateWindow would be returning NULL here? What debug output could I provide that could be helpful here? -Steve

1 0

Re: FW: wine-devel digest, Vol 1 #1391 - 17 msgs
by Andrew Lynch 15 Nov '02

15 Nov '02

> Date: Thu, 14 Nov 2002 18:23:49 -0800 (PST) > From: Steven Edwards <steven_ed4153(a)yahoo.com> > Subject: Re: Wine Fun Projects v0.2 > To: dpaun(a)rogers.com, Wine Devel > <wine-devel(a)winehq.com> > > You might want to add visual-mingw to the winelib > apps section. One > thing I recommened to Jermey > White a while back was that WINE might gain more of > a market share if > there was a easy way for > people that are writing Windows apps on Windows if > they had a IDE for > GCC that was cross-platform. > > I was thinking at the time of something like a > CrossOver Developer > Studio or something. > > Anyway the idea is to run Visual-Mingw under WINElib > and be able to > just recompile your Win32 app > that was built with Visual-Mingw and the w32api > package plus reduce > some of the redunancy Wine, > Mingw and ReactOS have by finding areas where we are > not in sync. > > It would be a bitch and a long term project but I > think its something > to think about. > > Thanks > Steven > Visual-Mingw sounds almost identical to DevEx found at http://sourceforge.net/projects/wingtk and http://www.bloodshed.net I am using their wGLADE tool for cygwin/GTK+ development presently and it works great under Win98. Andrew Lynch PS, all of these tools are GPL __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com

2 2

Re: WWN 144
by Brian Vincent (C) 15 Nov '02

15 Nov '02

> Hmm, what is wrong with this picture? What's wrong is you posted from two different email accounts and the XML parser only matched the last one (even though you'd posted something like 25 from the other acct.) And frankly I just don't care enough to bother fixing the stat script to try to match every person who has multiple accts. A bigger issue is the parser (both on WineHQ and Kernel Traffic) doesn't seem to deal with <dl>, <dd>, <dt>, and <tt> tags so a few of the threads ended up looking like crap. And that's something I'm going to try to get fixed. -brian

1 0

WWN 144
by Dustin Navea 15 Nov '02

15 Nov '02

Hmm, what is wrong with this picture? This week, 372 posts consumed 1216 K. There were 68 different contributors. 44 (64%) posted more than once. 43 (63%) posted last week too. The top 5 posters of the week were: " /> " /> 43 posts in 117K by Dimitrie O. Paun 27 posts in 72K by Sylvain Petreolle 26 posts in 85K by Tony Lambregts 2 posts in 4K by Dustin Navea 22 posts in 51K by Alexandre Julliard Pulled up in IE 6 and it showed that, even after refreshing. -Dustin

1 0

RE: C++ tests (1/2)
by Patrik Stridvall 15 Nov '02

15 Nov '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Many normal "C" features are not commonly used either, shouldn't we > > have tests for them? > > If all the C framework could do was test the alignment of a few rarely > used structures, then it would clearly not be worth the > trouble either. Perhaps. But that is only ONE of the things we could do. Unless you have noticed the meantion examples (repeated below) contains INLINE FUNCTIONS that needs to be tested not just alignment and that sort of things. < A FEW examples of C++ only features: < 1. The D3D math classes (vector, matrices, quaternions, colors etc) in < d3dvec.inl d3dx8math.inl d3dxmath.inl < 2. The GDI+ API classes in gdiplus*.h < 3. The DAO API classes in dbdao.h < 4. STL compatible classes for accessing SAFEARRAY's in t_safevector.h

1 0

RE: C++ tests (1/2)
by Patrik Stridvall 15 Nov '02

15 Nov '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > So my questions to you: > > 1. Should we support the C++ only features meantion above? > > 2. If yes, should we just include it in the tree without tests > > and just hope it works or should we have C++ tests for them? > > When someone has an app that requires these features they can > implement them, and test them by building their app. Or we can > implement them and write a small test program to test them once. The same can be said about every "C" feature as well. > No > need to build a new test environment for such uncommon features. Many normal "C" features are not commonly used either, shouldn't we have tests for them? Look, the point of tests is not testing once. It is testing for regressions when the code changes. > > I see no relevent comparsion between them: > > 1. C++ is actually used by the Microsoft SDK. Perl is not. > > 2. The Perl framework was big and required generated modules. > > The C++ framework is very small and uses the Wine header files > > as they are (or should be in order to be Microsoft compatiable) > > The issue is not really the size of the framework, it's the extra > dependencies. It would require everybody who wants to run tests to > have a working, compatible C++ installation; given the various levels > of brokenness of existing g++ versions that's far from trivial. Very true. Thanks for reminding me that it should be an optional feature. It you want to use it: ./configure --with-cxx No problem.

2 1

COM Enhancement patch
by Christian Costa 15 Nov '02

15 Nov '02

Hi all, I've sent a patch for ddraw COM management, I did not have any comments and the patch has been rejected. Could someone tell me if something is wrong or lacking? Christian. PS: I've joined a small doc that explains how to use objects with multiple interfaces. This docs is based on what has been done before with the ddraw code plus the enhancement I did. --------------------------------------------------------------------------------- - COM OBJECTS MANAGEMENT - --------------------------------------------------------------------------------- 1) Definitions: --------------- a) Object classes An object class is a structure wich defines the data of an object and all the interfaces that act on the object data Example : struct ObjectClass { INTERFACE 1; INTERFACE 2; ............ INTERFACE N; DATA; } ; typedef struct ObjectClass ObjectClass; b) Objects An object is a instance of an object class. Example : An object is created as follows : ObjectClass* object = malloc(sizeof(ObjectClass),...) c) Interfaces An interface is a way for an application to interact with an object. It contains a pointer to a virtual table plus some other data than can help objects management. An interface is a structure, which is used internally, that can be defined with the INTERFACE macro : #define INTERFACE(iface) \ struct { \ iface interface; \ /* VTABLE */ LPVOID object; \ /* pointer to the object the interface belongs to */ } To add a field to the interface, just add it in this macro. For example, we could embed the version number inside an interface or a magic number to check if the interface's pointer points to a real interface. And, off course, modify some macros or create new ones to make use of them. 2) Implementing COM objects: --------------------------- a) Declaring a COM object with multiple interfaces To declare interfaces in a COM object the ICOM_VFIELD_MULTI must be used for each interface as shown below: struct IDirect3DImpl { /* IUnknown fields */ ICOM_VFIELD_MULTI(IDirect3D); ICOM_VFIELD_MULTI(IDirect3D2); ICOM_VFIELD_MULTI(IDirect3D3); ICOM_VFIELD_MULTI(IDirect3D7); DWORD ref; /* IDirect3D fields */ IDirectDrawImpl* ddraw; LPVOID private; }; b) Creating an object Just declare an pointer to an object and allocate the memory for it. Example: IDirect3DImpl* object = malloc(sizeof(IDirect3DImpl),...) c) Initializing interfaces It is done with the ICOM_INIT_INTERFACE(object_pointer, interface_name, virtual_table) ICOM_INIT_INTERFACE(object,IDirect3D, VTABLE_IDirect3D); ICOM_INIT_INTERFACE(object,IDirect3D2,VTABLE_IDirect3D2); ICOM_INIT_INTERFACE(object,IDirect3D3,VTABLE_IDirect3D3); ICOM_INIT_INTERFACE(object,IDirect3D7,VTABLE_IDirect3D4); d) Retreive an object from within an interface's function If we consider the function : IDirect3D_AddRef(IDirect3D iface,.......) To retrieve a pointer to an object within the function, both followings macro are used : 1) ICOM_OBJECT(object_class,iface) This macro return an pointer to the object, the value is of object_class* type Example: IDirect3DImpl* d3d = ICOM_OBJECT(IDirect3DImpl,iface); 2) ICOM_THIS_OBJECT(object class,iface) It simply declares a This pointer and initialize it with the object address. IDirect3DImpl* This = ICOM_OBJECT(IDirect3DImpl,iface); e) Sharing functions between multiple interfaces In the case where a function does no have to do specific actions depending on the interface, you can share directly a function. Example : If we consider the function : IDirect3D_AddRef(IDirect3D iface,.......) The different virtual tables would be : VTABLE_IDirect3D = {......,IDirect3D_AddRef,....); VTABLE_IDirect3D2 = {......,XCAST()IDirect3D_AddRef,....); VTABLE_IDirect3D3 = {......,XCAST()IDirect3D_AddRef,....); VTABLE_IDirect3D7 = {......,XCAST()IDirect3D_AddRef,....); Note that this is possible because the ICOM_OBJECT can retreive the object's pointer without knowing the interface involved. f) Thunking interface Interface thunking enable changing from one interface to another. The following macro COM_INTERFACE_CAST(impltype, ifnamefrom, ifnameto, ifaceptr) performs this task. impltype = object class ifnamefrom = interface type we have ifnamefrom = interface type we want ifaceptr = pointer to the interface to cast return = pointer to the casted interface Interface thunking is a another way to shared a single function across different interfaces but as shown below this is required only when structures must be translated, interfaces returned casted or to handle prototype change : Example: You want to share the IDirect3D_CreateDevice across all IDirect3DX interfaces (with X above 1 because a device in Direct3D is created in a different way). IDirect3D2_CreateDevice(IDirect3D2* iface,.....) is the only one implementation of the function. The others are thunks to the IDirect3D2_CreateDevice. IDirect3D3_CreateDevice(IDirect3D3* iface, .....,LPDIRECT3DDEVICE3 *lpdevice, LPUNKNOWN lpUnk) { IDirect3DDevice3 *dev; IDirect3D_CreateDevice(ICOM_INTERFACE_CAST(IDirect3DImpl,IDirect3D2,IDirect3D3,iface),.....,&dev); *lpdevice = ICOM_INTERFACE_CAST((IDirect3DImpl,IDirect3D3,IDirect3D2,device) } IDirect3D7_CreateDevice(IDirect3D7* iface, .....,LPDIRECT3DDEVICE7 *lpdevice) { IDirect3DDevice2 *dev; IDirect3D_CreateDevice(ICOM_INTERFACE_CAST(IDirect3DImpl,IDirect3D2,IDirect3D7,iface),.....,&dev); *lpdevice = ICOM_INTERFACE_CAST((IDirect3DImpl,IDirect3D7,IDirect3D2,dev) } Here, we have to deal with a returned interface and a prototype change. The VTABLE should be: VTABLE_IDirect3D2 = {......,IDirect3D2_CreateDevice,....); VTABLE_IDirect3D3 = {......,IDirect3D3_CreateDevice,....); VTABLE_IDirect3D7 = {......,IDirect3D7_CreateDevice,....); Note that there are few functions that need this, for the others, thunks are not necessary and the way described in e) must be preferred. g) Getting an specific interface of an object With the ICOM_INTERFACE(implobj, ifacename) macro, any interfaces can be retreive from an object. implobj = pointer to the object ifacename = interface name we want return = pointer to an interface Example: IDirect3DImpl* object; ............ IDirect3D3* iface_d3d3 = ICOM_INTERFACE(object,IDirect3D3) h) Calling an COM object functions from another If a function is shared across multiple interfaces, you should write: IDirect3D3_CreateDevice(IDirect3D* iface,.....) { ICOM_THIS_OBJECT(iface); ................. IDirect3D_AddRef(ICOM_INTERFACE(This,IDirect3D),.....); ................. } If you know the nature of iface (i.e. thunking is used or the function is used in only one interface), you can write : IDirect3D3_CreateDevice(IDirect3D* iface,.....) { ICOM_THIS_OBJECT(iface); ................. IDirect3D3_AddRef(iface,.....); ................. }

6 6

Wine without any X11 environment
by Michael Riedel 15 Nov '02

15 Nov '02

Hello, is it possible to use wine in a telnet session to start a (command line) windows application? I get the error that x11drv can't connect to a display (which is correct). I'm also not very sure that the windows program itself does not perform some graphic related queries (there were some fixme messages when I tried to use 'ttydrv'). Any ideas? Is there any workaround to use a dummy display or whatever? Thanks, Michael --

3 3

Re: StgIsStorageFile
by Dmitry Timoshkov 15 Nov '02

15 Nov '02

"Ryan Cumming" <ryan(a)completely.kicks-ass.org> wrote: > On a side note, I made a pretty nice testcase for this, but there seems to be > no dlls/ole32/tests directory. Just send a file with tests to wine-patches and somebody else will make a makefile magic for you. -- Dmitry.

3 3

Re: wine/ programs/rundll32/rundll32.c dlls/kernel ...
by Martin Wilck 15 Nov '02

15 Nov '02

Am Fre, 2002-11-15 um 05.17 schrieb Alexandre Julliard: > ChangeSet ID: 6302 > Modified files: > programs/rundll32: rundll32.c > dlls/kernel : computername.c > > Log message: > Warning fixes. Your compiler seems to issue more warnings than mine :-/ It is good to see these patches are really reviewed. The lenW thingy is really embarrassing for me. Two questions/remarks: @@ -426,12 +426,13 @@ memcpy( name, buf, len ); name[len] = 0; *size = len; + ret = TRUE; This shouldn't be necessary because the whole block is executed only if ret == TRUE. } } __EXCEPT(page_fault) { SetLastError( ERROR_INVALID_PARAMETER ); - ret = FALSE; + return FALSE; } __ENDTRY What is the point of this one? (applies also to the last hunk) Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 1

RE: C++ tests (1/2)
by Patrik Stridvall 15 Nov '02

15 Nov '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Then of course we want normal C++ tests as well. Many (most?) > > applications likely to be ported by Winelib are C++ application > > so we really should have tests for possible C++ problems. > > The Wine tests are supposed to test the implementation, That is their primary use, yes. However I see no need to limit it to that. > not the > compilation. If some code interfaces incorrectly with Winelib, because of C++ problems or whatever, it doesn't really matter if the implementation is correct, does it? The result will still be wrong. Interface problems are inherently compilation specific. So yes, I really think we should have some tests for them. Sure I don't have much hope of catching that many bugs but then, it givens at least some confidence that the interface is reasonable bug free. > And building C++ apps with Winelib is a complex issue > that you won't be able to test in the Wine framework, except with > carefully tweaked code that won't match what real apps do anyway. > > Frankly, the likelihood of catching a real problem that way is much > too small to justify the complexity of a whole new test environment. What complexity? The patch is very small and half of it concerns the .c.cxx hack to compile tests with both with C and C++, that I can remove if you wish. Except for the file extension choping, it is possible to do with only changing "Makefile:s". Anyway if you don't accept the somewhat abstract argument above, here are some more concrete ones: How are we supposed to test specific C++ features in the Winelib header. Sure we doesn't have many yet, primarily because only C++ Winelib application needs then and we don't have any in the tree so we don't need that ourselves. But some (many?) C++ application ports from Windows certainly does. Sure we can add them to the Wine tree without any tests but if they are neither used internal nor tested they are very likely to be wrong. And yes, there are quite a lot of C++ only feature in the Microsoft SDK that are not in Wine yet. A FEW examples of C++ only features: 1. The D3D math classes (vector, matrices, quaternions, colors etc) in d3dvec.inl d3dx8math.inl d3dxmath.inl 2. The GDI+ API classes in gdiplus*.h 3. The DAO API classes in dbdao.h 4. STL compatible classes for accessing SAFEARRAY's in t_safevector.h Then of course we have COM... Sure we can test it in C to a large extent, but will it be enough? So my questions to you: 1. Should we support the C++ only features meantion above? 2. If yes, should we just include it in the tree without tests and just hope it works or should we have C++ tests for them? > We just got rid of the Perl framework, please let's not add a new one. I see no relevent comparsion between them: 1. C++ is actually used by the Microsoft SDK. Perl is not. 2. The Perl framework was big and required generated modules. The C++ framework is very small and uses the Wine header files as they are (or should be in order to be Microsoft compatiable)

2 1

Wine Fun Projects v0.2
by Dimitrie O. Paun 15 Nov '02

15 Nov '02

Folks, The second release (much expanded) of the Fun Project page has been released, in all it's glory, at: http://www.dssd.ca/wine/Wine-Fun-0.2.html The working version of the above is at: http://www.dssd.ca/wine/Wine-Fun.html By now, you should know that comments, suggestions, and flames are not only appreciated, but expected. -- Dimi.

4 6

Re: Quick question about ANSI and Unicode
by Dustin Navea 15 Nov '02

15 Nov '02

I fixed it, dang outlook defaults. Dustin ----- Original Message ----- From: "Tony Lambregts" <tony_lambregts(a)telusplanet.net> To: "Dustin Navea" <speeddymon(a)ev1.net> Sent: Friday, November 15, 2002 10:33 AM Subject: Re: Quick question about ANSI and Unicode > Dustin Navea wrote: > > > Ok, as you may have noticed Dimi sent a couple of patches that were > > supposed to fix Treeview Notifies a couple of weeks back. They didnt > > exactly work, but its not that the code he submitted didnt help. > > Basically when running the StarCraft installer in wine, it attempts to > > display the treeview-based directory listing in unicode which isnt > > supported by that installer, and so it ends up not showing anything. > > I was wondering if anyone thinks that the fact that my TextCP=0 in the > > wine config file has anything to do with it. I'm thinking that if I > > set it to TextCP=1252 or TextCP=437 then it will work as expected, but > > I have no way of testing this until tonight, as I'm not on a Linux box > > right now, being at work and all. Just thought I would check with > > everyone and see what they thought. > > > > Comments appreciated. > > > > I am sorry I can't help with the codepage thing. However, I am sure > that you didn't mean to, but you sent this in html format, and you know > this list is text only... Do you need some help with setting up outlook > to send text only? > > -- > > Tony Lambregts > > > >

1 0

RE: Wine without any X11 environment
by Patrik Stridvall 15 Nov '02

15 Nov '02

> is it possible to use wine in a telnet session to start a > (command line) > windows application? Yes. > I get the error that x11drv can't connect to a > display (which is correct). I'm also not very sure that the windows > program itself does not perform some graphic related queries (there were > some fixme messages when I tried to use 'ttydrv'). If the application directly or indirectly loads GDI32.DLL or USER32.DLL it also load the x11drv with the result above if DISPLAY isn't set. > Any ideas? Is there any workaround to use a dummy display or whatever? In addition to the ttydrv (as you meantion above) you can use VNC like: vncserver :1 export DISPLAY=:1

1 0

Adding -lc when linking?
by Gerald Pfeifer 15 Nov '02

15 Nov '02

When compiling Wine on FreeBSD, there are tons of warnings of the following kind (and have been that way since I can remember) which regularily cause confusion and support requests by people building our port: /usr/bin/gcc -shared -Wl,-Bsymbolic glu32.spec.o glu.o glu32.dll.dbg.o -o glu32.dll.so -L../../dlls -L../../library -lwine -L/usr/X11R6/lib -lSM -lICE -lXxf86dga -lXxf86vm -lXv -lXext -lX11 -lGL -lGLU -lm /usr/lib/libgcc.a(_op_vdel.o): In function `__builtin_vec_delete':_op_vdel.o(.text+0x45): undefined reference to `free' /usr/lib/libgcc.a(_op_delete.o): In function `__builtin_delete':_op_delete.o(.text+0x45): undefined reference to `free' /usr/lib/libgcc.a(_op_new.o): In function `__builtin_new':_op_new.o(.text+0x1aa): undefined reference to `malloc' /usr/lib/libgcc.a(exception.o): In function `__eh_alloc': exception.o(.text+0xa5): undefined reference to `malloc' /usr/lib/libgcc.a(exception.o): In function `__eh_free': exception.o(.text+0xc9): undefined reference to `free' /usr/lib/libgcc.a(tinfo2.o): In function `type_info::before(type_info const &) const': tinfo2.o(.text+0x14): undefined reference to `strcmp' Alfred (Cc:ed) verified that these warnings can be eliminated by o getting rid of the -Wl,-Bsymbolic option (which you probably want to keep to actually get warnings linking symbols are hosed), or o explicitly adding -lc. Would you mind making one of these changes (neither should break GNU/Linux)? If not, how should this problem be addressed? Gerald PS: Please Cc: Alfred and me when replying, as we are not on this list. -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

1 0

Quick question about ANSI and Unicode
by Dustin Navea 15 Nov '02

15 Nov '02

Ok, as you may have noticed Dimi sent a couple of patches that were supposed to fix Treeview Notifies a couple of weeks back. They didnt exactly work, but its not that the code he submitted didnt help. Basically when running the StarCraft installer in wine, it attempts to display the treeview-based directory listing in unicode which isnt supported by that installer, and so it ends up not showing anything. I was wondering if anyone thinks that the fact that my TextCP=0 in the wine config file has anything to do with it. I'm thinking that if I set it to TextCP=1252 or TextCP=437 then it will work as expected, but I have no way of testing this until tonight, as I'm not on a Linux box right now, being at work and all. Just thought I would check with everyone and see what they thought. Comments appreciated. -Dustin

1 0

Re: rpc_J_PL0-r1
by Greg Turner 15 Nov '02

15 Nov '02

On Friday 15 November 2002 07:42 am, Greg Turner wrote: > This is basically just a resend of the old rpc_J_PL0 patch, but fixed > to go in cleanly against the current CVS, since rundll32 (trivially) > broke my old patch. oops: +++ ./programs/Makefile.in 2002-11-15 07:29:36.000000000 -0600 @@ -57,6 +58,8 @@ progman \ regedit \ regsvr32 \ + rpcss \ + rpcss \ uninstaller \ wcmd \ wineconsole \ I'll save you all the bandwith of fixing this.... -- gmt "War is an ugly thing, but not the ugliest of things; the decayed and degraded state of moral and patriotic feeling which thinks that nothing is worth war is much worse. A man who has nothing for which he is willing to fight; nothing he cares about more than his own personal safety; is a miserable creature who has no chance of being free, unless made and kept so by the exertions of better persons than himself." -- John Stuart Mill

1 0

something with Chinese character processing
by yf 15 Nov '02

15 Nov '02

I found that to show Chinese character properly. Following should be modified: in wine-2002????/graphics/x11drv/codepage.c static Xchar2b *X11DRV_unicode_to_char2b_cp936(fontObject *pfo, LPCWSTR lpwstr, UINT count) { ... for(i=0; i<count; i++, str_src++, str2b_dsg++) { if(IsLegalDBCSChar_cp936(*str_src, *(str_src+1))) { // modified begin ===> str2b_dst->byte1=*str_src&0x7f; str2b_dst->byte2=*(str_src+1)&0x7f; str_src++; // <=== modified end } else ... } ... } But there still some character can't be properly showed. Where I lost should be modified, please tell me. Best regards. /yf

1 0

something with Chinese character processing
by yf 15 Nov '02

15 Nov '02

1 0

Another msvcrt replacement
by Fabian Cenedese 15 Nov '02

15 Nov '02

Hi Looks like wine is not the only one in need of MS replacements. They're only at version 0.0.1 but maybe they have something wine could use or wine sure has something they could use... http://mingwacr.sourceforge.net/ bye Fabi

1 0

Wine Time Line
by Thomas Wickline 15 Nov '02

15 Nov '02

Hi, I have been looking over the FAQ and we have a question in the FAQ " What is the History of Wine" And after talking with Dimi Paun I would like to expand this to a " Wine Time Line" page that could be updated a couple times a year. This would give users info about wine's progression & events that took place over the years. Here is a draft of the first year 1993/1994..... Done by _Robert Amstadt_ -- A discussion began on USENET about the feasibility of running Windows apps on Linux. There were some people that said that it is impossible. This didn't sit well with Robert Amstadt so he began work to prove them wrong. He started out by writing a program loader for Win3.1 apps. Alexandre Julliard merged windowing functions written by Peter MacDonald in Tcl/Tk to the program loader written by Robert. Alexandre soon after rewrote everything to eliminate the Tcl/Tk in favor of direct calls to Xlib. Eric Youngdale also contributed early in many areas including improvements to the program loader. The very first Wine mailing list was operated by Robert to allow discussions between developers. After a year with many successes and growing interest in the project we asked for the creation of the newsgroup comp.emulators.ms-windows.wine. The vote was overwhelmingly in favor of its creation. Around the same time, Robert was asked to give a presentation about Wine at the first Linux Congress in Heidelberg, Germany. The room was packed. Interest in Wine was very high. During the first year of development, most of the code was written by Alexandre Julliard and Robert Amstadt. However, we have always received contributions of code from many people. Life got busy for Robert and he stepped down as head of the project and let Alexandre take control. It was probably sometime during the second year. -- Thoughts, Volinteers, Flames are most welcome.. Thomas

3 2

RE: C++ tests (1/2)
by Patrik Stridvall 15 Nov '02

15 Nov '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > In the case of generated.c it is very useful since > > alignment and that sort of thing might pontially be different > > with C++. For other normal tests I'm not sure how useful > > it is to tests with C++ as well. It can't hurt of course > > but then it takes twice as long to run... > > I don't see what this buys us at all. If the C++ compiler generates > different structure layouts from the same headers then it is broken, > but that's not really a Wine problem. First of all it was just an example what it could be used for. It is the only thing that winapi_test (tests/generated.c) currently tests for. However, there will be more tests in the future testing for other things that might or might not be C++ dependent. Secondly the test makes certain that you don't have a #ifdef __cplusplus affecting some structure by mistake. And yes, there are structure like that MONITORINFO that does. And no, don't look in the Wine source, it doesn't implement it yet. Then we could have #ifdef __cplusplus that have an "missing" #endif that matches some other #endif in the wrong place or something. We also have the COM interfaces that are different in C++... Then of course we want normal C++ tests as well. Many (most?) applications likely to be ported by Winelib are C++ application so we really should have tests for possible C++ problems. But it you don't like the .c.cxx hack I could generate C++ tests to a generated_cxx.cxx or whatever then we don't need that part of the patch. It is a little ugly I admit. :-)

2 1

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