wine-devel

wine-devel@winehq.org

9 participants
84458 discussions

Re: GTA3 crash :( -- RedHat 9
by Ann and Jason Edmeades 14 Aug '03

14 Aug '03

I dont think GTA3 has ever worked yet as it uses palettes and I dont recall us ever finishing it (Raphael is the one to ask). However, try commenting out the line in directx.c : object->visInfo = glXChooseVisual(object->display, DefaultScreen(object->display), dblBuf); This has caused problems on some manufacturers device drivers. Its something we need to fix, but there's also numerous other things... There's no demo for gta3 last time I looked :-( Jason

4 4

Re: wine/programs/regedit regproc.h regproc.c rege ...
by Vincent Béron 14 Aug '03

14 Aug '03

Le jeu 14/08/2003 à 15:36, Dustin Navea a écrit : > --- Vincent Béron <vberon(a)mecano.gme.usherb.ca> wrote: > > @@ -153,6 +153,9 @@ > > } > > } > > > > + if (*s && action == ACTION_UNDEF) > > + action = ACTION_ADD; > > + > > if (action == ACTION_UNDEF) > > return FALSE; > > > > > > <IMHO> I think this would be a little cleaner (or at least easier to read): > > if (*s && action == ACTION_UNDEF) > action = ACTION_ADD; > else if (action == ACTION_UNDEF) > return FALSE; Sure, I agree with that. I was a bit in a hurry yesterday, when I noticed while building RH8 and RH9 RPMs that I had a regedit window (when the import was supposed to stay windowless) and that the file hadn't be imported. My first goal was to get it to work correctly. > > that or > > if (action == ACTION_UNDEF) > { > if (*s) > action = ACTION_ADD; > return FALSE; > } This won't do the same thing (the return statement will always be executed). Vincent

2 1

Re: wine/programs/regedit regproc.h regproc.c rege ...
by Vincent Béron 14 Aug '03

14 Aug '03

Le mer 06/08/2003 à 23:10, Alexandre Julliard a écrit : > ChangeSet ID: 8934 > CVSROOT: /home/winehq/opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/08/06 22:10:13 > > Modified files: > programs/regedit: regproc.h regproc.c regedit.c Makefile.in > .cvsignore > Added files: > programs/regedit: treeview.c rsrc.rc resource.rc resource.h > main.h main.c listview.c framewnd.c childwnd.c > about.c En.rc > > Log message: > Robert Dickenson <robd(a)reactos.org> > Steven Edwards <Steven_Ed4153(a)yahoo.com> > Mike McCormack <mike(a)codeweavers.com> > Implemented GUI for regedit. > > Patch: http://cvs.winehq.com/patch.py?root=/home/winehq/opt/cvs-commit&id=8934 regedit.c: @@ -153,10 +154,13 @@ } if (action == ACTION_UNDEF) - { - action = ACTION_ADD; + return FALSE; + + return PerformRegAction(action, s); } This seems to have broken commandline only regedit, for the ACTION_ADD case (used in wineinstall et al.). The included patch should fix it (building in progress). Vincent

2 2

Small Winecfg win version patch
by root 14 Aug '03

14 Aug '03

This patch adds Windows 2k3 to the winecfg program. -- E. C. F. Wolff Note: Based on Beron's version patch for version.c

2 1

GTA3 crash :( -- RedHat 9
by root 14 Aug '03

14 Aug '03

Hey, After been away too long I'm back again :). Thirst thing what I did was checking that GTA3 still worked. But it didn't :( After it produced a lot of CheckDeviceMultiSampleType fixme's it produced this screen :(: fixme:d3d:IDirect3D8Impl_CheckDeviceMultiSampleType (0x4a7d0460)->(Adptr:0, DevType:(1,D3DDEVTYPE_HAL), SurfFmt:(17,D3DFMT_R5G6B5), Win?0, MultiSamp:b) fixme:d3d:IDirect3D8Impl_CheckDeviceMultiSampleType (0x4a7d0460)->(Adptr:0, DevType:(1,D3DDEVTYPE_HAL), SurfFmt:(17,D3DFMT_R5G6B5), Win?0, MultiSamp:c) fixme:d3d:IDirect3D8Impl_CheckDeviceMultiSampleType (0x4a7d0460)->(Adptr:0, DevType:(1,D3DDEVTYPE_HAL), SurfFmt:(17,D3DFMT_R5G6B5), Win?0, MultiSamp:d) fixme:d3d:IDirect3D8Impl_CheckDeviceMultiSampleType (0x4a7d0460)->(Adptr:0, DevType:(1,D3DDEVTYPE_HAL), SurfFmt:(17,D3DFMT_R5G6B5), Win?0, MultiSamp:e) fixme:d3d:IDirect3D8Impl_CheckDeviceMultiSampleType (0x4a7d0460)->(Adptr:0, DevType:(1,D3DDEVTYPE_HAL), SurfFmt:(17,D3DFMT_R5G6B5), Win?0, MultiSamp:f) fixme:d3d:IDirect3D8Impl_CheckDeviceMultiSampleType (0x4a7d0460)->(Adptr:0, DevType:(1,D3DDEVTYPE_HAL), SurfFmt:(17,D3DFMT_R5G6B5), Win?0, MultiSamp:10) fixme:d3d:IDirect3D8Impl_CheckDeviceFormat (0x4a7d0460)->(Adptr:0, DevType:(1,D3DDEVTYPE_HAL), AdptFmt:(23,D3DFMT_R5G6B5), Use:(2,D3DUSAGE_DEPTHSTENCIL), ResTyp:(1,D3DRTYPE_SURFACE), CheckFmt:(73,D3DFMT_D15S1)) fixme:d3d:IDirect3D8Impl_CheckDepthStencilMatch (0x4a7d0460)->(Adptr:0, DevType:(1,D3DDEVTYPE_HAL), AdptFmt:(17,D3DFMT_R5G6B5), RendrTgtFmt:(17,D3DFMT_R5G6B5), DepthStencilFmt:(49,D3DFMT_D15S1)) fixme:d3d:IDirect3D8Impl_CreateDevice Requested full screen support not implemented, expect windowed operation X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 145 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 488 Current serial number in output stream: 488 I think the last functions (RendrTgtFmt and ImplCreateDevice) are responsible for the crash or could it be my openGL setup (I think not, because it worked before) -- E. C. F. Wolff

1 0

Another problem wih Charlie's Angels
by Dominik.Strasser＠t-online.de 14 Aug '03

14 Aug '03

ReHi, after hacking Wine for the problem in my previous mail I got further, but no success yet. The problem is: Charlie's Angels unpacks a "System.dll" into a temporary directory and tries to load it. But as there is a compiled-in loadorder default which says "builtin", the builtin 16bit system.dll is loaded which results in a failure. Only commenting the loadorder helped. Neither --dll nor DllOverrides worked. Perhaps we need a more sophisticated loadorder detection. Regards Dominik PS: Now as the game is installed, it doesn't work. It crashes right at the begining even before the game is loaded. I'll dig deeper into this.

1 0

Re: [winegcc03] winewrap can handle the default output name
by Dimitrie O. Paun 14 Aug '03

14 Aug '03

On August 13, 2003 09:55 pm, Richard Cohen wrote: > Default name that mingw uses is a.exe > This also stops winewrap from segfaulting when passed no arguments. > > Changelog > Handle default linker output name (a.exe) in winewrap The reason I've handled it in winegcc rather than winewrap is that this seems to be a (historical) feature that's specific to gcc, and there doesn't seem to be any reason to have such a feature perpetuated in winewrap. -- Dimi.

2 2

Fwd: Re: status of Kazaalite crash patch ?
by Dimitrie O. Paun 14 Aug '03

14 Aug '03

-- Dimi.

1 0

Re: [X11DRV] Re-add support for the 'UseXShm' config key.
by Alexandre Julliard 14 Aug '03

14 Aug '03

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > Changelog: > - the UseXShm key was still present but not used anymore Do you actually need it? Otherwise I think we might as well remove it completely, clearly nobody depends on it since it has been broken for a long time. -- Alexandre Julliard julliard(a)winehq.com

2 3

winevdm: can't exec
by Dominik.Strasser＠t-online.de 14 Aug '03

14 Aug '03

Hi, trying to run the game demo of "Charlie's Angels" which can be found here: http://www.gamesdomain.com/demos/demo/1861.html I am running into a strange problem. The demo is a NE binary, so winevdm is called. But is has the "32-bit-flag" set, so MODULE_LoadModule16 returns handle 21 (Win32 binary). Consequently winevdm emits "can't exec". By hacking __wine_process_init to start WIN16 binaries as WIN32, I am proceeding much further. Should I modify MODULE_GetBinaryType to look for the above mentioned 32-bit-flag and to return a new binary type which is treated like PE ? Regards Dominik

1 0

Re: [winegcc01] Don't use BINDIR to spawn subprograms
by Dimitrie O. Paun 14 Aug '03

14 Aug '03

On August 13, 2003 09:49 pm, Richard Cohen wrote: > Just using $PATH to find stuff makes it much easier to spawn off tools > when running within the tree. > > Changelog: > Remove hardcoded BINDIR paths Yes, this is a problem -- eventually we want to use these things from within the tree. I guess we can prepend $WINE_HOME/tools to the PATH within the Makefile. Another way do to it is to look at argv[0], and if we're running from within the tree, we automatically select the in-tree tools, rather than the ones from BINDIR. What do people think, any other suggestions? -- Dimi.

2 1

Re: Implementations of WCSToMBEx and MBToWCSEx and PolyPatBlt
by Dimitrie O. Paun 14 Aug '03

14 Aug '03

On August 13, 2003 10:10 pm, Jonathan Wilson wrote: > Here are the implementations of those functions I did for ReactOS. (and no, > I didnt use disassembler on them this time :) > I am licencing them under whatever licence I need to in order for them to > go into WINE (if the WINE team wants them that is) > They compile on ReactOS just fine. Not sure if they work or not, tests > would be usefull :) Please submit them as a patch, so that Alexandre can apply them to the tree like all the other patches. > BTW, I can also share some of the info I have on other user32 functions I > was able to figure out/find info on if there is a need for it. Sure, more info can't hurt (if you got it through legal means :)). -- Dimi.

2 2

status of Kazaalite crash patch ?
by wim delvaux 14 Aug '03

14 Aug '03

Hi, Read on the devel archive (using search) about crashing Kazaalite .. I can confirm. I have the same problem since 200306 version. Just upgraded to 200307 but still crashes. What's the status of this problem ? W

2 1

Re: [resend 3rd time ] SetMenu patch
by Alexandre Julliard 13 Aug '03

13 Aug '03

Oleg Prokhorov <xolegpro(a)rbcmail.ru> writes: > Cause: > SetMenu was limited to update client/non-client only if window is > visible, while MS Windows SetMenu updates it anyway. > > Changelog: > SetMenu always updates client/non-client. This causes a SetWindowPos to happen during window creation, before the window is properly initialized, with bad results. This will need more work I'm afraid. -- Alexandre Julliard julliard(a)winehq.com

1 0

finaly vacations
by Raphaël Junqueira 13 Aug '03

13 Aug '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I'll be on vacation (and most of the time off line) for 2 weeks. Finaly after a lot of hard work at office (and few time for wine), some holydays. The return will be "hot" ;=) Best Regards, Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/OmjDp7NA3AmQTU4RAstGAJ0TUuXqNHciWD6MUodk540dJ/NFHACeOM15 QW0K5IHbtqblTS6KJFtOPC4= =c05x -----END PGP SIGNATURE-----

1 0

winver
by puoti＠inwind.it 13 Aug '03

13 Aug '03

I've noticed that wine doesn't yet seem to have a winver option for windows server 2003, I suppose it a trivial thing to implement, at least by seeing how quickly this was done for windows xp.

3 6

Re: Other winefile fixes
by Dimitrie O. Paun 13 Aug '03

13 Aug '03

On August 13, 2003 09:25 am, Richard Cohen wrote: > Use __WINE instead of _WINE_, _WIN32 Why do we need to know that we're running under Wine in so many places? I think we have fewer tests for __WINE__ in a huge lib like wxWindows than we have in winefile! -- Dimi.

2 1

Re: wrong keyboard layout
by Dmitry Timoshkov 13 Aug '03

13 Aug '03

"Phil Krylov" <phil(a)newstar.rinet.ru> wrote: > XFree86 -version reports: > > XFree86 Version 4.3.0 > Release Date: 27 February 2003 > X Protocol Version 11, Revision 0, Release 6.6 > Build Operating System: Linux 2.4.22_pre2-gss i686 [ELF] > Build Date: 23 July 2003 > > The log you asked for is attached. It's rather big, so I truncated it > after ToUnicode entries. Here is your problem: trace:x11drv:x11drv_init_thread_data Using C locale of Input Method XFree86 uses C locale, not UTF-8 one. As I wrote previously, test with 'xev' first. As soon as it starts to work, Wine should work as well. -- Dmitry.

2 2

Re: Other winefile fixes
by Dimitrie O. Paun 13 Aug '03

13 Aug '03

On August 13, 2003 09:25 am, Richard Cohen wrote: > Dimi, I have some patches for winegcc/winewrap. Are you working on it > at the moment, or should I just send them to wine-patches? Don't worry about me, send whatever you have to wine-patches. -- Dimi.

1 0

__stdcall__ pointer to member function
by Boaz Harrosh 13 Aug '03

13 Aug '03

the GCC (3.2.2) compiler will not let me declare an __stdcall__ pointer to function member and code will than SEGFAULT on invocation of the member pointer. This is not the case for Regular pointers to functions. ( The compiler will also issue a warning on mismatch.) Listing of the Error: (BAD) class AFoo { public: __attribute__((__stdcall__)) void foo(int i ,int ii ,int iii) ; } ; __attribute__((__stdcall__)) void AFoo::foo(int i ,int ii ,int iii) { return ; } int main() { AFoo afoo ; void ( AFoo::*func)(int,int,int) ; func = &AFoo::foo ; for(int i=0 ; i < 0x8000000 ;i++) (afoo.*func)(1,2,3) ; // SEGFAULT or SEGIL when stack is Exhausted return 0 ; } any attempt to place the __atribute__((stdcall)) in the pointer declaration causes a compilation error. With out it the code will SEGFAULT. If declaring a regular pointer to function than no compilation error is issued and all is well. Listing of Regular function pointer: (GOOD) void __attribute__((stdcall)) foo(int i ,int ii ,int iii) { } int main() { void ( __attribute__((stdcall)) *func)(int,int,int) = &foo ; for(int i=0 ; i < 0x8000000 ;i++) (func)(1,2,3) ; return 0 ; } removing the __attribute__((stdcall)) from the *func declaration will rightfully issue a warning ( should be an error if you ask me, type mismatch). But Not so on our first example. !!!!!!!!!!!!!!!!!! Please if any body can help me? This totaly breaks COM. Is there a GCC switch to have all members (and pointers)__stdcall, to by pass this problem? Free Life Boaz

1 1

Re[2]: wrong keyboard layout
by Phil Krylov 13 Aug '03

13 Aug '03

Hello Shachar, Tuesday, August 12, 2003, 12:15:51 AM, you wrote: SS> Dmitry Timoshkov wrote: >>BTW, what wrong happens if your keyboard was misdetected? In the current >>CVS all national characters should work fine regardless what keyboard >>layout was detected. Is that only a warning message which makes you worry? >> >> SS> Does this also apply to UTF-8? I, for one, still can't get any SS> characters recognized when the locale is UTF-8. With the current CVS, I can't get any Cyrillic input with any setting of LANG: ru_RU.KOI8-R, ru_RU.UTF-8, ru_RU.CP1251, and en_US.UTF-8. Only ? characters are input. -- Best regards, Phil mailto:phil@newstar.rinet.ru

2 7

Better GNOME integration
by Christian Neumair 13 Aug '03

13 Aug '03

When trying to use the latest Debian package I noted that there are no MIME bindings available for GNOME and that applications installed with wine are not visible in the application menu. In my opinion the first issue is really easily solvable, just three more files need to be included in the package and copied into /usr/share/mime-info and /usr/share/application-registry - is the official source the right place or should package maintainers include this? The second is a bit more tricky. I propose that as a 1.0 target wine should implement the freedesktop.org menu spec [1], which is definitly the future. We should contact the freedesktop guys and tell them that we want a registered category "WINE" :). regs, Chris [1] http://www.freedesktop.org/standards/menu-spec/0.5-onehtml/

1 0

WCSToMBEx and MBToWCSEx
by Jonathan Wilson 13 Aug '03

13 Aug '03

I have come up with some info on these 2 (previously undocumented) calls: DWORD STDCALL WCSToMBEx(WORD CodePage,LPWSTR UnicodeString,DWORD UnicodeSize,LPSTR *MBString,DWORD MBSize,BOOL Allocate); DWORD STDCALL MBToWCSEx(WORD CodePage,LPSTR MBString,DWORD MBSize,LPWSTR *UnicodeString,DWORD MBSize,BOOL Allocate); Return value for both is the count of characters copies (or mabie count of bytes, not sure) for WCSToMBEx, the parameters are: CodePage: specifies which code page to use (its the same code page as passed to WideCharToMultiByte) UnicodeString: the input unicode string UnicodeSize: the size of the unicode string (not sure if its bytes or characters). Pass -1 to ask the function to calculate it for you. MBString: the output ascii string MBSize: the size of the ascii string (not sure if its bytes or characters). Pass -1 to ask the function to calculate it for you. Allocate: Set to true to ask the function to allocate the destination memory. Set to false and it assumes that the memory is preallocated by the caller. For MBToWCSEx, the parameters are: CodePage: specifies which code page to use (its the same code page as passed to MultiByteToWideChar) MBString: the input ascii string MBSize: the size of the ascii string (not sure if its bytes or characters). Pass -1 to ask the function to calculate it for you. MBString: the output unicode string MBSize: the size of the unicode string (not sure if its bytes or characters). Pass -1 to ask the function to calculate it for you. Allocate: Set to true to ask the function to allocate the destination memory. Set to false and it assumes that the memory is preallocated by the caller. I am going to implement these functions and contribute the code to ReactOS & WINE but I want someone else to play whith them and confirm all my findings as to what these functions do and how they work first.

3 2

Question about dlls/dinput/mouse/main.c
by Michael Schlüter 12 Aug '03

12 Aug '03

Hi, I've a small problem with the game "Star Trek Elite Force II Single Player Demo". The mouse button event seems not to be send back to the game. After changing the return value of dinput_mouse_hook in dlls/dinput/mouse/main.c to return always "CallNextHookEx( This->hook, code, wparam, lparam );" it works. Does anybody has a solution for that issue? Bye, Michael

1 0

Re: Implement a typelib loader cache
by Alexandre Julliard 12 Aug '03

12 Aug '03

Mike Hearn <mike(a)theoretic.com> writes: > ChangeLog: > Implement a typelib loader cache You'll need to protect the list with a critical section. Also it's probably better to store the list directly in the typelib structure instead of allocating a separate object. -- Alexandre Julliard julliard(a)winehq.com

1 0

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