- Wine-devel - list.winehq.org

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

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

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