wine-devel September 2004

wine-devel@winehq.org

131 participants
282 discussions

Re: Wine Developer Cheatsheet, v1
by Rolf Kalbermatter 07 Sep '04

07 Sep '04

"Diego 'Flameeyes' =?ISO-8859-1?Q?Petten=F2?=" wrote: >I have only a doubt: > >> - Is it possible to implement the ANSI version by converting to unicode >> then calling the wide version, rather than duplicate it? > >How can I convert an ansi string to a unicode one and reverse? So I can redo >the patch with the calls :) Typically you use MultiByteToWideChar() for any input strings and then WideCharToMultiByte() for possible output strings. You can look at shlwapi/path.c and other files in there to see how this is usually done. Depending on the place where you do it, it might be preferable to use dynamically allocated buffers instead of using stack space as Wine is already using quite a lot of stack. Principle: WCHAR *textW; INT countW = MultiByteToWideChar(CP_ACP, 0, textA, -1, NULL, 0); if((textW = HeapAlloc(GetProcessHeap(), 0, countW * sizeof(WCHAR)))) { MultiByteToWideChar(CP_ACP, 0, textA, -1, textW, countW); /* Do the Widechar call */ HeapFree(GetProcessHeap(), 0, textW); } Rolf Kalbermatter

4 4

RE: iostream and msvcrt?
by Scott Snell 07 Sep '04

07 Sep '04

Hi Dimi, Thanks for helping out. I made the changes you suggested to the gcc-mingw.mak file for STLPort. When I go make it does a: wineg++ -I../stlport -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -mno-cygwin -O2 -D_STLP_USE_DYNAMIC_LIB dll_main.cpp -c -o ../lib/obj/MINGW32/ReleaseD/dll_main.o which throws up a world of errors, such as: In file included from ../stlport/cstdlib:25, from ../stlport/stl/debug/_debug.c:160, from ../stlport/stl/debug/_debug.h:418, from ../stlport/utility:40, from dll_main.cpp:35: /usr/include/c++/3.3.2/cstdlib:97: error: `div' not declared /usr/include/c++/3.3.2/cstdlib:102: error: `ldiv' not declared /usr/include/c++/3.3.2/cstdlib: In function `ldiv_t std::div(long int, long int)': I'm sure its something simple but I'm still not comfortable around gcc/winegcc. thanks, Scott. > -----Original Message----- > From: Dimitrie O. Paun [SMTP:dpaun@rogers.com] > > On Wed, Aug 18, 2004 at 11:32:33AM +0300, Boaz Harrosh wrote: > > > > > Better go with gcc-mingw.mak, as threading and OS is more Windows than > > Linux. See if they have a -nocygwin variant. > > Yes, it should work with the gcc-mingw.mak by changing > gcc -> winegcc > g++ -> wineg++ > > > >adding a path pointing to /include/wine/MSVCRT. > > > > > No, you shouldn't need that. You just need to make sure you pass > the -mno-cygwin flag to winegcc/wineg++. > > -- > Dimi.

3 2

Re: PathSearchAndQualify and other shlwapi fixes
by Robert Shearman 07 Sep '04

07 Sep '04

Diego 'Flameeyes' Pettenò wrote: >Ok thanks to Mike and Rofl I was able to clean the patch up (at least I hope >so :) > >ChangeLog: >- Write partially PathSearchAndQualify (there is a FIXME) with A->W call >[dlls/shlwapi/path.c] >- Add to PathCreateFromUrl support for file:/// urls (with 3 '/' ) >[dlls/shlwapi/path.c] >- Add to UrlCanonicalize the URL_FILE_USE_PATHURL flag's support. >[dlls/shlwapi/url.c] >- Add to UrlIs support for URLIS_DIRECTORY and URLIS_FILEURL flags >[dlls/shlwapi/url.c] >- Fixes UrlCreateFromPath [dlls/shlwapi/url.c] > > One patch for each atomic change please. It makes it easier to review and more likely to get the changes into CVS. Rob

1 0

Using winelib in python module
by Nikolay A. Liber 07 Sep '04

07 Sep '04

Hi All Have anybody tried to use winelib in python modules? I need to make python bindings to some propritary DLL that available as a binary only. I made shared library that simply dynamicaly loads that DLL using winelib mono hack. It works perfectly when I link it with simple C test program but crashes when I load in python module. Just a call to SharedWineInit() causes python to crash Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1075433600 (LWP 2477)] server_init_process () at ../../include/winnt.h:1543 1543 __asm__(".byte 0x64\n\tmovl (0x18),%0" : "=r" (teb)); (gdb) bt #0 server_init_process () at ../../include/winnt.h:1543 #1 0x40497ca7 in thread_init () at thread.c:141 #2 0xbfffc588 in ?? () #3 0x40039500 in dlerror () from /lib/tls/libdl.so.2 #4 0x00000000 in ?? () #5 0xbfffd830 in ?? () #6 0xbfffc588 in ?? () #7 0x404b6140 in forcedWinVersion () from /usr/local/lib/wine/ntdll.dll.so #8 0x4003af54 in ?? () from /lib/tls/libdl.so.2 #9 0x00001f98 in ?? () #10 0x00000000 in ?? () #11 0x00000000 in ?? () #12 0x404b7000 in ?? () #13 0x00001f98 in ?? () #14 0x4003003b in pthread_rwlockattr_setkind_np () from /lib/tls/libpthread.so.0 #15 0x400390b0 in dlsym () from /lib/tls/libdl.so.2 #16 0x4003af54 in ?? () from /lib/tls/libdl.so.2 #17 0xbfffd830 in ?? () #18 0xbfffd830 in ?? () #19 0xbfffc5f8 in ?? () #20 0x40039096 in dlsym () from /lib/tls/libdl.so.2 #21 0x0817fd70 in ?? () #22 0x404b4820 in __JCR_LIST__ () from /usr/local/lib/wine/ntdll.dll.so #23 0xbfffd830 in ?? () #24 0xbfffd820 in ?? () #25 0xbfffc5f8 in ?? () #26 0x40480e48 in __wine_process_init (argc=-1995430796, argv=0xe804245c) at loader.c:2036 Previous frame inner to this frame (corrupt stack?) (gdb) If there are any ways to initialize winelib from python module may be other than mono hack? Please answer by mail fw(a)tehn.ru Thank you

2 1

Re: Wine and industrial communication like OPC
by Rickard Svensson 07 Sep '04

07 Sep '04

----- Original Message ----- From: Juan Lang <juan_lang(a)yahoo.com> Date: Sun, 5 Sep 2004 21:59:37 -0700 (PDT) To: riq(a)mail.com Subject: Re: Wine and industrial communication like OPC > > * We want to make a OPC server, because other > > computers want to get information from our system. > > Is there a problem in make a DCOM server, is it the > > "no user can acsas port under 1024 on a Linux > > system" problem. > > It's a problem for lots of reasons. They add up to > this: this is unimplemented in Wine, and probably > won't be implemented any time soon. To bad, I ges that it wil take same time to inplement all the parts of DCom in Wine ;( > > * What I have heard I thought DCom uset RPC??? But > > Juan Lang wrote that Wine doesn't have support for > > RPC > > Did I? I certainly didn't mean it. But you'd need to > install the DCOM98 update to have any chance of > success at it for now, at least if I read the code > right. You wrote: < Date: Thu, 2 Sep 2004 08:27:49 -0700 (PDT) < From: Juan Lang <juan_lang(a)yahoo.com> < This method would allow us to act as a CIFS (TCP port 445) client. < Acting as an SMB (TCP port 139) client isn't handled by the CIFS < module, it's done by the SMBFS module. Not sure what Steve's < plans are here. < Anyway, any of you guys interested in seeing RPC work under Wine < (Greg, you still lurking around here?) might want to play around < with this if you have time. I might myself once I land somewhere < for a while, but no promises. But perhaps I grabd that out of contens, you ment in this case. Thanks a lot Juan for you answer! /Rickard -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

Re: RESEND: CreateDIBitmap: Don't create monochrome bitmaps
by Dmitry Timoshkov 07 Sep '04

07 Sep '04

"Huw D M Davies" <h.davies1(a)physics.ox.ac.uk> wrote: > + /* Need to check if the bitmap is monochrome, and if the > + two colors are really black and white */ > + if (is_dib_monochrome(pbi)) > + { > + /* Top-down DIBs have a negative height */ > + DWORD height = pbi->bmiHeader.biHeight; > + if (height < 0) height = -height; [skipped] > + /* If it's possible, create a monochrome bitmap */ > + > + DWORD height = fix_info->bmiHeader.biHeight; > + if (height < 0) height = -height; In the code above 'DWORD height' should be changed to 'LONG height' otherwise the test 'height < 0' will always fail. -- Dmitry.

1 0

D3D7: textures, mipmaps, DDSCAPS_COMPLEX
by andrejoh＠c2i.net 06 Sep '04

06 Sep '04

Hi! First some good news (for me at least): Cedega from CVS can now be used to play Anarchy Online! [1] To get this working, Marius Grigoriu had to implement support for DDSCAPS_COMPLEX in the Cedega code; this support seems to be lacking in Wine. I've had a look at the patch, and both the Cedega and Wine implementations -- they are quite similar, but do have some differences in the texture creation part. In particular, Cedega has a lot of additional code in create_texture, and the parts in Wine's version seems to reside in the function create_mipmaps in the Cedega file (dlls/ddraw/ddraw/main.c). As far as I've understood things, the Cedega DDraw code is under the AFPL license, and cannot be merged with the Wine LPGL code; thus I've not looked further into that (the changes seems to be related to cube map support). However, the patch from Marius is released under the X11 license, and can be applied to Wine with minor tweaking (due to support for compressed textures in the Wine code). Should this be applied to the Wine tree (depending on me having ported it correctly, of course)? For reference, I've included the related part from the original patch as well (see also [1]). Unfortunately, even with this patch, running AO under Wine crashes with some texture related code: First chance exception: divide by zero in 32-bit code (0x419c6d5c). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:003b GS:0033 EIP:419c6d5c ESP:4085e784 EBP:4085e7e4 EFLAGS:00210246( - 00 -RIZP1) EAX:00000000 EBX:00000002 ECX:00000000 EDX:00000000 ESI:4085e958 EDI:00000002 Stack dump: 0x4085e784: 4085e984 4085e928 40530088 0000007c 0x4085e794: 0010180f 00000100 00000100 00000200 0x4085e7a4: 00000000 00000000 00000000 00000000 0x4085e7b4: 50bb0000 00000000 00000000 00000000 0x4085e7c4: 00000000 00000000 00000000 00000000 0x4085e7d4: 00000000 00000020 00000041 00000000 Backtrace: =>1 0x419c6d5c _D3DXLoadTextureFromSurface@28+0x3e9 in randy31d (0x4085e7e4) 2 0x00007c00 (0x00000010) 3 0x00000000 (0x00000000) 0x419c6d5c _D3DXLoadTextureFromSurface@28 in randy31d: divl 0x40(%ebp),%eax Wine-dbg>bt Backtrace: =>1 0x419c6d5c _D3DXLoadTextureFromSurface@28+0x3e9 in randy31d (0x4085e7e4) 2 0x00007c00 (0x00000010) 3 0x00000000 (0x00000000) Doing "bt all" crashes the debugger with this message after getting a listing of one thread: wineserver: debugger.c:477: debugger_detach: Assertion `event->sender->debug_event == event' failed. I've been unable to figure out what happens here, but I assume it might be caused by an invalid texture surface. Hacking in the AO code base (as in disabling certain textures), I've been able to get all the way into the client, but with almost no rendering. Any further help would be greatly appreciated! [1] http://www.csh.rit.edu/~marius/aolinux/ -- Try Anarchy Online http://www.anarchy-online.com/content/downloads/tryout/ Netiquette guidelines ftp://ftp.rfc-editor.org/in-notes/rfc1855.txt How to quote properly http://www.i-hate-computers.demon.co.uk/ Hvordan sitere riktig http://home.online.no/~vidaandr/news/OBSquoting.html

1 0

Re: CreateDirectoryW improvement
by Uwe Bonnes 06 Sep '04

06 Sep '04

>>>>> "Wolfgang" == Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> writes: Wolfgang> Description: Return error ERROR_ALREADY_EXISTING if an Wolfgang> existing drive (e.g. 'C:') without '\\' is specified Wolfgang> ChangeLog: CreateDirectoryW: Return error Wolfgang> ERROR_ALREADY_EXISTING e.g. for path 'C:' Wolfgang> Index: dlls/kernel/path.c Wolfgang, having some test cases in our test suite for those problems is a good idea... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Don't crash on failing DRIVER_FindFromHDrvr
by Uwe Bonnes 06 Sep '04

06 Sep '04

Hallo, I sent a patch to prevent wine from crashing last friday. It happend, when DRIVER_FindFromHDrvr returned NULL. No I found out, that I had sent that patch before last year. Eric answered > this doesn't seem right to me: either the loading fails and we shouldn't > get a valid handle, or it succeeds and we should be able to find it > there's must be something wrong elsewhere > could you please send a -debugmsg +driver,+module,+winmm to see what > happens ? and like before, I can't reproduce the error after reverting the patch: > the error no longer exists. I guess some registry entry was corrupt and a > successfull run corrected it later. > > However I see a lot of check after DRIVER_FindFromHDrvr() in other parts of > the code... If one dose "grep -3 DRIVER_FindFromHDrvr wine/dlls/winmm/*", every other usage of DRIVER_FindFromHDrvr is like if ((lpDrv = DRIVER_FindFromHDrvr(hDrvr)) != NULL) Why should expecting a NULL return be wrong? It happens, as the the crashes show. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 4

Re: Battlefield 1942 d3d8 crash
by Ann and Jason Edmeades 06 Sep '04

06 Sep '04

Does changing the line 575 (in device.d, dlls/d3d8) to be if (ppBackBuffer) IDirect3DSurface8Impl_AddRef((LPDIRECT3DSURFACE8) *ppBackBuffer); make any difference - Looks like the app is doing an odd way to work out how many back buffers there are. Jason

2 2

← Newer
1
...
20
21
22
23
24
25
26
...
29
Older →

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 September 2004