wine-devel

wine-devel@winehq.org

4 participants
84464 discussions

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