wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: APPDB: Half-Life and Counter-Strike with WINE
by Hiji 10 May '05

10 May '05

--- "David F. Colwell" <dfcolwell(a)dfcolwell.com> wrote: > Hiji et al, > > Couldn't find Half-Life or Counter-Strike in the DB > yet they returned... > > Submitted version rejected > ------------------------------------------------------- > The version you submitted ( 1.0.0.0) has been > rejected.This application is already in the > database. If you are interested in helping out with > the howto please sign up to be a maintainer of the > application. Thanks. > We appreciate your help in making the Version > Database better for all users. > > Best regards. > The AppDB team > http://www.winehq.org/ > > > I did my part. :-) > On Monday 09 May 2005 7:40 pm, Hiji wrote: > > Any ideas? (I'm forwarding the message, so, it > > defaults to showing below my message. Sorry!) :( --- Chris Morgan <cmorgan(a)alum.wpi.edu> wrote: > I plugged 'half-life' into the search box and got: > > http://appdb.winehq.org/search.php?q=half-life > > Looks like its working here. What did you search > for? > > I just added 'halflife' as a keyword to the > half-life application so searching > for 'halflife' also returns the appropriate results. > > Chris I found it too, but I believe the problem was that he was trying to add a specific version (1.0.0.0), and he got the error. The versions I see on there are 1.1.0.8 and 1.1.1.0 David, can you elaborate for us? Hiji Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html

3 3

UT2003 regression, Windowing problem
by Ann and Jason Edmeades 10 May '05

10 May '05

Hi all, I'm trying to track down a regression which causes UT2003 (and UT2004 / Unreal2 apparently) to fail, and am getting stuck at the windowing level so would appreciate any thoughts as to possible causes. (And no, I haven't tried to work out what regressed it... Why spoil my fun!) Basically we enter RedrawWindow and continually loop because the window in question never gets repainted 'properly'. The window has just been created, and very little has happened on the window other than being activated. A +tid,+win,+msg,+x11drv,+spy (with various extra debug code in) shows: Initial pass into RedrawWindow is via UpdateWindow which forces a redrawnow 0009:fixme:win:UpdateWindow In updateWindow 0009:trace:win:RedrawWindow 0x1002e whole window flags: RDW_ALLCHILDREN RDW_UPDATENOW 0009:fixme:win:RedrawWindow redraw hrgn Because of flags, we insist we redraw the screen now... 0009:fixme:win:RedrawWindow @@@> Redrawwindow calling updatenow? 256 0009:fixme:win:RedrawWindow @@@> Calling.... (We never leave the update_now routine) 0009:fixme:win:update_now Before wait We wait for outstanding painting related events. The window has just been created, so its just a clear of the whole screen from 0009:trace:x11drv:X11DRV_Expose win 0x1002e (3000006) 0,0 648x507 0009:trace:x11drv:X11DRV_Expose @@@> 0x1002e B4 Offset into rect (0,0)-(648,507) 0009:trace:x11drv:X11DRV_Expose @@@> 0x1002e Offset into rect (-4,-23)-(644,484) 0009:trace:win:RedrawWindow 0x1002e rect (-4,-23)-(644,484) flags: RDW_INVALIDATE RDW_ERASE RDW_ALLCHILDREN RDW_FRAME 0009:fixme:win:RedrawWindow redraw rects 0009:fixme:win:RedrawWindow @@@> Redrawwindow calling updatenow? 0 So the outstanding event was an invalidate of the whole area 0009:fixme:win:update_now After wait 0009:fixme:win:update_now @@> Calling erase 0009:fixme:win:update_now @@> Called erase The infinite for loop 0009:fixme:win:update_now @@> FOR loop prev=(nil) child=0x40027bec The window needs redrawing 0009:fixme:win:update_now Paint required! 0009:trace:msg:WINPROC_CallProc32WTo32A func 0x11017650 (hwnd=0x1002e,msg=WM_PAINT,wp=00000000,lp=00000000) ***> Nothing happens here as a result of the paint? 0009:fixme:win:update_now @@> FOR loop prev=0x1002e child=0x1002e So the invalid region is still set, so its assumed the updates have failed so we schedule a complete erase 0009:fixme:win:update_now @@@> 0x1002e not repainted properly, erasing 0009:trace:win:update_now 0x1002e not repainted properly, erasing 0009:fixme:win:update_now 0x1002e region 0x150c box (4,23)-(644,503) In send_erase 0009:trace:msg:WINPROC_CallProc32WTo32A func 0x11017650 (hwnd=0x1002e,msg=WM_ERASEBKGND,wp=000014ac,lp=00000000) 0009:trace:win:RedrawWindow 0x1002e rect (0,0)-(640,480) flags: RDW_INVALIDATE RDW_ERASE RDW_NOCHILDREN 0009:fixme:win:RedrawWindow redraw rects 0009:fixme:win:RedrawWindow @@@> Redrawwindow calling updatenow? 0 0009:fixme:win:send_erase Out send_erase So we loop again... 0009:fixme:win:update_now @@> FOR loop prev=(nil) child=0x1002e 0009:fixme:win:update_now Paint required! 0009:trace:msg:WINPROC_CallProc32WTo32A func 0x11017650 (hwnd=0x1002e,msg= WM_PAINT,wp=00000000,lp=00000000) ***> Nothing happens here as a result of the paint? Etc etc 0009:fixme:win:update_now @@> FOR loop prev=0x1002e child=0x1002e 0009:fixme:win:update_now @@@> 0x1002e not repainted properly, erasing 0009:trace:win:update_now 0x1002e not repainted properly, erasing etc etc So should there have been an action as a result of the WM_PAINT, and is it valid for it not to occur (ie is wine overdoing the assumption on redrawing) Is updatenow correct for an UpdateWindow call (MSDN states a WM_PAINT should be sent, but doesn't say it will check it gets done). Note there are 2 suspicious patches in painting.c both by AJ - (1.19 and 1.20) - The first tries to handle broken WM_PAINT handlers by avoiding the loop, and the 2nd (1.20) just forces the loop to occur! Adding a 'break' in the case where child==prev and a send ncpaint / send erase has occurred avoids the problem, but what is the correct fix Jason

3 2

games
by Ivan Leo Puoti 10 May '05

10 May '05

If you've got a safedisk1 copy protected game please contact me by private email. All safedisk1 games have a .ICD file in the root of the CD. Ivan.

1 0

[Fwd: Re: Commercial support]
by StartCom Ltd. 10 May '05

10 May '05

Or maybe just because of it, there is a need for commercial support, or somebody might need that support. If it would be running, by just clicking on the executable, no support is really needed, at least not for standard applications. IBM does very well know the existents of Wine (they even acknowledged that by themselves lately), but may very well not support it, because of inter-relation with MS. As of now (just a guess), they don't want to get into more hot water right now.... gslink wrote: > Go to the Wine HQ site and click on applications database. If you > need more applications check the listed links. > This is a problem with every development effort and nobody is blaming > anybody. The larger the effort the worse it gets. This is probably > the worst problem both Microsoft and IBM have with code. If you > change anything in Wine something somewhere will probably quit > running. This is simply the price of progress. My comment, and it is > not a criticism, is that Wine still has rough edges. Eventually these > will go away but for now, you can't simply load Wine into Linux and > blindly start loading in applications. The more complex the > application the more likely it needs setup. As versions progress > setup procedures change and as a result things quit running. > Microsoft Office doesn't run without setup and neither do many of the > older games such as Alice or Rune. Even things like Warcraft come and > go. This is not a criticism it is just the way things are and that is > why I think it is too early to start thinking about commercial support. > What somebody needs to do now is to get a relationship with IBM > similar to the one that Eclipse has. IBM has a problem currently > because there is no native Lotus Notes client for Linux. Wine could > easily solve this problem. I talked to some of the marketing managers > in IBM and most had never heard of Wine. The IBM development labs are > currently starting to develop this native client. If IBM could use > Wine it could save them money and sueing Wine is one thing sueing IBM > is another. > > -- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org <http://www.startcom.org/> MediaHost^(TM) at www.mediahost.org <http://www.mediahost.org/> Skype: startcom <callto://startcom/> Phone: +1.213.341.0390 Import StartCom Public CA <http://cert.startcom.org/index.php?app=109>

2 1

Re: [QCAP] patch 4, Adding enumPins object
by Paul Vriens 10 May '05

10 May '05

> Changelog > - dlls/qcap/Makefile.in > - dlls/qcap/enumpins.c > Add IEnumPins object for use by other class objects. This is taken > from quartz with only minor adaptions. > > Rolf Kalbermatter > > > +WINE_DEFAULT_DEBUG_CHANNEL(quartz); Shouldn't that be qcap ? Cheers, Paul.

1 0

Re: Commercial support
by gslink 10 May '05

10 May '05

I recently took the list of applications from headquarters that are listed as running properly and found that many of these are available for little cost. I bought a few and tried to run them. Not a one ran as is from the box. I was able to get all of them to run with some trouble. One big problem I see with Wine is that there is no good testing. As versions progress things quit running and the author has no way of knowing. I have no good solution for this problem but I suspect that it needs attention. It is, of course, part of the documentation problem. It is not in the nature of programmers to document their work.

3 4

Re: dlls/opengl32: fix WGL_ACCELERATION_ARB queries from applications
by Raphael 10 May '05

10 May '05

On Monday 09 May 2005 11:09, Aric Cyr wrote: > Just a small patch to Raphael's recent CVS commit which added a much > better wglChoosePixelFormatARB() and friends. This patch fixes the > return values that an application will recieve when it queries the > WGL_ACCELERATION_ARB pixel format attribute. good catch :) Regards, Raphael

2 1

Re: Make test status - latest CVS
by Juan Lang 10 May '05

10 May '05

--- Shachar Shemesh <wine-devel(a)shemesh.biz> wrote: > >I don't see the same thing here. Could you send me a heap trace? > > > Aw, man! You were sitting right behind me when that happened. Couldn't > you have taken my laptop and debugged it on the spot then? :-) I wanted to have a chance to run it, read over the code, etc. I'm afraid I don't see the problem still. Maybe a storage,heap trace? --Juan __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

1 0

APPDB: Half-Life and Counter-Strike with WINE
by Hiji 09 May '05

09 May '05

Any ideas? (I'm forwarding the message, so, it defaults to showing below my message. Sorry!) :( Note: forwarded message attached. __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail

2 1

Window management - what to do next?
by Vitaliy Margolen 09 May '05

09 May '05

Ok, I've been digging this stuff for more then a week now. And I still don't have even a partial understanding of what's going on in there. If someone please explain me these: 1. Where wine stops and passing over to X/window manager? I'm most interested in handling focus changes, minimize/maximize/restore. 2. What are we doing about properly implementing minimize/maximize/restore. Here is what I uncovered so far about SetWindowPos: 1. Wine does not send WM_WINDOWPOSCHANGING/WM_WINDOWPOSCHANGED. 2. Wine does not redraw owner/owned windows (or not in a proper order) when z-order changes. It looks like these heavily depend on focus changes and owner/owned windows relations. Some times native redraws both owner and owned windows. Sometimes none at all. Same goes for messages. I'm kind of stuck here. To go any further I need to know what part should we delegate to WM and what part do ourselves. -- Best regards, Vitaliy

2 1

Regression in start wars jedi knight: jedi academy
by Stefan Dösinger 09 May '05

09 May '05

Hello, I've yet another problem with the OpenGL patches from April 28: Star Wars Jedi Knight: Jedi Academy crashes during startup. The problematic commit is http://www.winehq.org/hypermail/wine-cvs/2005/04/0308.html, it's not the same problem as with Half-life. The crash happens in ntdll in HEAP_CreateFreeBlock. The call trace shows EDIT_MakeFit on wine/dlls/user/edit.c as the function which calls the heap functions. The crash only occurs if the game's configuration file exists, so the first start succeeds, but the following calls fail. I've attached 3 +opengl,+edit traces: before.out: Game start with config file and without the mentioned wine patch after.out: Game start with config file and with the patch applied(crash) nocfg.out: Game start without config file and with the patch(no crash) Any ideas? The whole thing looks quite strange as the crash is not directly related to OpenGL. Stefan The crash dump is: wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x77cfff70 in 32-bit code (0x77ec1139). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:77ec1139 ESP:77a7e588 EBP:77a7e5a8 EFLAGS:00010283( - 00 -RIS1C) EAX:77d00000 EBX:77ef6d8c ECX:77efdb1c EDX:00110000 ESI:77cfff70 EDI:77c3bcb0 Stack dump: 0x77a7e588: 77a7e5c4 77ec198f 77bf0000 77efdb1c 0x77a7e598: 77ec221d 77ef6d8c 00000848 77c3b460 0x77a7e5a8: 77a7e5c4 77ec14a6 77bf0000 77c3bcb0 0x77a7e5b8: 000c42c0 77c3b460 77c3b468 77a7e61c 0x77a7e5c8: 77ec2c3e 77bf0000 77c3b460 00000848 0x77a7e5d8: 00000001 77a7e5ec 77ec2e40 77bf001c Backtrace: =>1 0x77ec1139 HEAP_CreateFreeBlock+0x69(subheap=0x77bf0000, ptr=0x77c3bcb0, size=0xc42c0) [heap.c:447] in ntdll (0x77a7e5a8) 2 0x77ec14a6 HEAP_ShrinkBlock+0x56(subheap=0x77bf0000, pArena=0x77c3b460, size=0x848) [heap.c:543] in ntdll (0x77a7e5c4) 3 0x77ec2c3e RtlReAllocateHeap(heap=0x77bf0000, flags=0xa, ptr=0x77c3a5a8, size=0x848) [heap.c:1348] in ntdll (0x77a7e61c) 4 0x77b33774 HeapReAlloc(heap=0x77bf0000, flags=0x8, ptr=0x77c3a5a8, size=0x848) [/windows/c/sonstiges/wine/dlls/kernel/heap.c:280] in kernel32 (0x77a7e638) 5 0x77b33f76 GlobalReAlloc+0x1b6(hmem=0x77c3641a, size=0x840, flags=0x42) [/windows/c/sonstiges/wine/dlls/kernel/heap.c:617] in kernel32 (0x77a7e668) 6 0x77b3457d LocalReAlloc+0x2d(handle=0x77c3641a, size=0x840, flags=0x42) [/windows/c/sonstiges/wine/dlls/kernel/heap.c:926] in kernel32 (0x77a7e680) 7 0x77148793 EDIT_MakeFit+0x1a3(es=0x77c36368, size=0x41e) [/windows/c/sonstiges/wine/dlls/user/edit.c:1787] in user32 (0x77a7e6b0) 8 0x7714b24f EDIT_EM_ReplaceSel+0x17f(es=0x77c36368, can_undo=0x0, lpsz_replace=0x77c38a58, send_update=0x1, honor_limit=0x1) [/windows/c/sonstiges/wine/dlls/user/edit.c:3045] in user32 (0x77a7e718) 9 0x77145e84 EditWndProc_common+0x634(hwnd=0x1002c, msg=0xc2, wParam=0x0, lParam=0x77a7e958, unicode=0x0) [/windows/c/sonstiges/wine/dlls/user/edit.c:617] in user32 (0x77a7e794) 10 0x77146c1c EditWndProcA(hWnd=0x1002c, uMsg=0xc2, wParam=0x0, lParam=0x77a7e958) [/windows/c/sonstiges/wine/dlls/user/edit.c:1016] in user32 (0x77a7e7b0) 11 0x7719ecef WINPROC_wrapper+0x17 in user32 (0x77a7e7d4) 12 0x7719f056 WINPROC_CallWndProc+0x76(proc=0x77146bf0, hwnd=0x1002c, msg=0xc2, wParam=0x0, lParam=0x77a7e958) [/windows/c/sonstiges/wine/dlls/user/winproc.c:419] in user32 (0x77a7e80c) 13 0x771a5fe7 CallWindowProcA(func=0x77146bf0, hwnd=0x1002c, msg=0xc2, wParam=0x0, lParam=0x77a7e958) [/windows/c/sonstiges/wine/dlls/user/winproc.c:3216] in user32 (0x77a7e840) 14 0x77170c61 call_window_proc+0x171(hwnd=0x1002c, msg=0xc2, wparam=0x0, lparam=0x77a7e958, unicode=0x0, same_thread=0x1) [/windows/c/sonstiges/wine/dlls/user/message.c:1521] in user32 (0x77a7e89c) 15 0x77172cbf SendMessageTimeoutA+0x1ff(hwnd=0x1002c, msg=0xc2, wparam=0x0, lparam=0x77a7e958, flags=0x0, timeout=0xffffffff, res_ptr=0x77a7e92c) [/windows/c/sonstiges/wine/dlls/user/message.c:2399] in user32 (0x77a7e908) 16 0x77172db1 SendMessageA+0x51(hwnd=0x1002c, msg=0xc2, wparam=0x0, lparam=0x77a7e958) [/windows/c/sonstiges/wine/dlls/user/message.c:2443] in user32 (0x77a7e934) 17 0x00454613 in jamp (+0x54613) (0x0000001f) 18 0x00000000 (0x00000000) 0x77ec1139 HEAP_CreateFreeBlock+0x69 [heap.c:447] in ntdll: movl 0x0 (%esi),%ecx Unable to open file 'heap.c' Modules: Module Address Debug info Name (70 modules) PE 0x00400000-01327000 Export jamp PE 0x10000000-100f2000 Deferred openal32 ELF 0x712fc000-71376000 Deferred libglu.so.1 ELF 0x71376000-71410000 Deferred opengl32<elf> \-PE 0x713b0000-71410000 \ opengl32 ELF 0x71a5b000-71a70000 Deferred midimap.drv<elf> \-PE 0x71a60000-71a70000 \ midimap.drv ELF 0x71b8c000-71bb0000 Deferred msacm32<elf> \-PE 0x71b90000-71bb0000 \ msacm32 ELF 0x71bb0000-71bc9000 Deferred msacm.drv<elf> \-PE 0x71bc0000-71bc9000 \ msacm.drv ELF 0x71bc9000-71c0e000 Deferred wineoss.drv<elf> \-PE 0x71be0000-71c0e000 \ wineoss.drv ELF 0x71c5b000-71c7a000 Deferred imm32<elf> \-PE 0x71c60000-71c7a000 \ imm32 ELF 0x71c7a000-71c7e000 Deferred iso8859-1.so ELF 0x71c85000-71ca2000 Deferred ximcp.so.2 ELF 0x71ca2000-71ca5000 Deferred xlcdef.so.2 ELF 0x71ca5000-71cae000 Deferred libxcursor.so.1.0.2 ELF 0x71cae000-71cb6000 Deferred libxrender.so.1 ELF 0x761e5000-761ed000 Deferred libgcc_s.so.1 ELF 0x761ed000-76201000 Deferred librt.so.1 ELF 0x762d5000-76b65000 Deferred fglrx_dri.so ELF 0x76b65000-76c09000 Deferred libgl.so.1 ELF 0x76c09000-76cd4000 Deferred libx11.so.6 ELF 0x76dd4000-76df6000 Deferred libexpat.so.0 ELF 0x76df6000-76e20000 Deferred libfontconfig.so.1 ELF 0x76e20000-76e34000 Deferred libz.so.1 ELF 0x76e4e000-76ecf000 Deferred libfreetype.so.6 ELF 0x76ecf000-76ef9000 Deferred ws2_32<elf> \-PE 0x76ee0000-76ef9000 \ ws2_32 ELF 0x76ef9000-76f16000 Deferred wsock32<elf> \-PE 0x76f00000-76f16000 \ wsock32 ELF 0x76f16000-76f36000 Deferred iphlpapi<elf> \-PE 0x76f20000-76f36000 \ iphlpapi ELF 0x76f36000-76f80000 Deferred rpcrt4<elf> \-PE 0x76f50000-76f80000 \ rpcrt4 ELF 0x76f80000-7700e000 Deferred ole32<elf> \-PE 0x76fa0000-7700e000 \ ole32 ELF 0x7700e000-7704e000 Deferred advapi32<elf> \-PE 0x77020000-7704e000 \ advapi32 ELF 0x7704e000-770dd000 Deferred gdi32<elf> \-PE 0x77060000-770dd000 \ gdi32 ELF 0x770dd000-7720f000 Stabs user32<elf> \-PE 0x77100000-7720f000 \ user32 ELF 0x7720f000-77290000 Deferred winmm<elf> \-PE 0x77220000-77290000 \ winmm ELF 0x77ad8000-77bf0000 Stabs kernel32<elf> \-PE 0x77b00000-77bf0000 \ kernel32 ELF 0x77d09000-77d13000 Deferred libnss_files.so.2 ELF 0x77d13000-77d1d000 Deferred libnss_nis.so.2 ELF 0x77d1d000-77d32000 Deferred libnsl.so.1 ELF 0x77d32000-77d3b000 Deferred libnss_compat.so.2 ELF 0x77d55000-77d78000 Deferred libm.so.6 ELF 0x77d78000-77e6d000 Deferred libwine_unicode.so.1 ELF 0x77e87000-77f00000 Stabs ntdll<elf> \-PE 0x77ea0000-77f00000 \ ntdll ELF 0x77f00000-77f03000 Deferred <wine-loader> ELF 0x77f41000-77f4f000 Deferred libxext.so.6 ELF 0x77f4f000-77f54000 Deferred libxxf86vm.so.1 ELF 0x77f54000-77f5a000 Deferred libxxf86dga.so.1 ELF 0x77f5a000-77f72000 Deferred libice.so.6 ELF 0x77f72000-77f7b000 Deferred libsm.so.6 ELF 0x77f7b000-78000000 Deferred x11drv<elf> \-PE 0x77f90000-78000000 \ x11drv ELF 0xb7e47000-b7e4b000 Deferred libdl.so.2 ELF 0xb7e4b000-b7f62000 Deferred libc.so.6 ELF 0xb7f62000-b7fb4000 Deferred libpthread.so.0 ELF 0xb7fb4000-b7fcd000 Deferred libwine.so.1 ELF 0xb7fe8000-b8000000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 (D) G:\jedi academy\GameData\jamp.exe 00000009 0 <== WineDbg terminated on pid 0x8

3 6

[Fwd: [Bug 2931] Diablo 2 video test fails]
by Dustin Navea 09 May '05

09 May '05

Bug 2931 is a regression, and we have found the patch which causes it. It is attached to the bug, and I have requested a link to the commit email, so that the appropriate person can know to take a look. Thanks Dustin -------- Original Message -------- Subject: [Bug 2931] Diablo 2 video test fails Date: Mon, 9 May 2005 03:30:31 -0500 From: Wine Bugs <wine-bugs(a)winehq.org> Reply-To: wine-devel(a)winehq.org To: wine-bugs(a)winehq.org http://bugs.winehq.org/show_bug.cgi?id=2931 ------- Additional Comments From rmh(a)debian.org 2005-09-05 03:30 ------- Got it. The commit that broke wine was done between 23:45 and 23:59 (i'm not sure wether UTC or my timezone, UTC+2). I don't need to track it down to the last second because this is the only commit in that interval (made by julliard). The patch that caused this regression is attached. I've verified that the patch can be reverted cleanly on current CVS, and once reverted wine works again for the Diablo 2 installer. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

Re: [OpenGL] Fwd: Re: Regression in Half life
by Jesse Allen 09 May '05

09 May '05

On 5/9/05, Raphael <fenix(a)club-internet.fr> wrote: > > while Waiting for a better idea: > > Changelog: > - fix x11drv/ChoosePixelFormat to choose 24 bpp as 32 bpp for depth buffers > (needed as many X11 drivers only support 24bpp) > > Regards, > Raphael > Are there any drivers that don't have 24 bpp but have 32 bpp instead? I think I remember seeing that before.

1 0

Wiki stuff
by Mike Hearn 09 May '05

09 May '05

Hi, It seems some users have started creating pages that are simply intended to dupe the appdb: http://wiki.winehq.com/Running_Errors http://wiki.winehq.com/WindowsGames I doubt it makes any sense to have this sort of info on the wiki. What do others think? thanks -mike

3 5

Re: [?? Probable Spam] notepad: add .LOG feature
by Dmitry Timoshkov 09 May '05

09 May '05

"Kevin Koltzau" <kevin(a)plop.org> wrote: > See http://support.microsoft.com/?kbid=260563 > > Changelog > Handle notepad log feature > + /* If the file starts with .LOG, add a time/date at the end and set cursor after > + * See http://support.microsoft.com/?kbid=260563 > + */ > + if (GetWindowTextW(Globals.hEdit, log, sizeof(log)/sizeof(log[0])) && !lstrcmp(log, dotlog)) Shouldn't it be a case insensitive comparison, i.e. does ".log" work as well? -- Dmitry.

2 1

Commercial support
by gslink 09 May '05

09 May '05

I wouldn't worry about anyone but Microsoft stealing Wine. In order to develop Wine you must be an expert C++ programmer. That requires an enormous amount of work and thieves are usually lazy. A new teacher came to the master. "I have developed some new techniques that make teaching much better." "How can I prevent other teachers from stealing them?" "Your worry is needless", replied the master. "If your techniques are any good you will have to force others to use them." With that the master threw an eraser at him. The same can be said about Wine and Microsoft.

3 3

qcap
by Maarten Lankhorst 09 May '05

09 May '05

this is my qcap dll in its current state, because i dont have much time in the next couple of weeks I' d thought I'd post it, perhaps someone can make it work with the new qcap dll implementation, what i have here is a pretty much complete version of qcap + a near complete version of V4l implementation (if i recall correctly, only YUV formats are missing now.. and V4L2 support but I'm *NOT* going to add that anyway) What files need to be added for vfwcapture? enumpins.c, media.c, null.c, pin.c, v4l.c, vfwcapture.c (+ perhaps some headers..) although julliard doesn't like copying media.c, enumpins.c and pin.c from quartz, it was the only way to make it work.. (I'm still not sure if he believes me though..) I tested this stuff by using msn webcam settings, if you want to transmit to someone else, you need a native version of msvfw32, else it won't work bonus points if you make this work through the wine driver model (dlls/winmm?), and write a patch for avicap32 to use winmm too (at least for capgetdriverdescription), I don't know how wine drivers work but you could try it. (I hope julliard allows the first version to use V4l in qcap..) If there are questions just ask.. I'm off to study for the big exams now.. Maarten

1 0

Revisiting exceptions
by Mike Hearn 09 May '05

09 May '05

Hi Alexandre, I got bored and took a stab at doing proper SEH macros using some GCC extensions I found. These are rather rough, unfinished definitions, and they aren't tested at all but do they look OK? thanks -mike static void __wine_frame_cleanup( __WINE_FRAME *wineframe ) { __wine_pop_frame(&wineframe->frame); } #define __TRY \ { \ __label__ __frame_label; \ __WINE_FRAME __f __attribute__((cleanup(__wine_frame_cleanup))); \ if (0) { \ __frame_label: #define __EXCEPT(func) \ } \ else { \ __f.frame.Handler = __wine_exception_handler; \ __f.u.filter = (func); \ __wine_push_frame( &__f.frame ); \ goto __frame_label; \ } \ }

7 11

Re: winecfg: Add wine configuration tab
by Alexandre Julliard 09 May '05

09 May '05

James Hawkins <truiken(a)gmail.com> writes: > This seemed to get pretty good support in wine-devel. The rest of the > implementation will follow soon. You really only want the dir symlink and hidden file options, and these should most likely be under the Drives tab. It doesn't make sense to let users edit the Windows or System dir, this will break everything. And there's no point in having a "wine" tab, all options in winecfg are about Wine anyway. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Re: Regression in Half life
by fenix＠club-internet.fr 09 May '05

09 May '05

Hi, <snip> >Uh, no, this doesn't help :-( > >Half-life supports only 16bpp(well, I can set it to other values with regedit, >but it seems to have no effect), fglrx supports 24bpp only. No problem here. >I switched to the Xorg radeon driver which has 16 bpp support(the 2nd column >shows 16 now), and made sure that hl runs with 16bpp, but the error still >occurs. > Yes it don't work, because you speak about frame buffer (named Color buffer on traces) when you speak about 16bpp. I spoke about depth buffer <snip> > - Depth : 32 <---- Is half-Life still trying to get 32bpp????? Yes, but not 32bpp for frame buffer only for depth buffer (usually Z-buffer) >But even if it worked this way, this wouldn't be a good solution for ATI >users, because playing newer games with the "radeon" driver is horrible. >(e.g. Jedi Academy, gl-117, even tuxracer makes problems). > >Removing the failing check from Wine's opengl code doesn't help, it causes a >hard crash later. Yes because game expect 32bpp for Depth buffer and if game try to read directly into this buffer you'll have some problems Regards, Raphael

3 3

Commercial support
by gslink 09 May '05

09 May '05

I wonder if it isn't a little early to consider the entire issue of commercial support. Most programs do not run under Wine without some sort of setup and things written to XP standards don't run at all. The project hasn't gotten to the 1.0 level yet. The project is coming along very well and sometime in the future will reach a 1.0 level. Might it not be time to consider things like this when the project has progressed a little further. I believe the project could better spend this effort publicizing Wine to groups such as the Smalltalk community. It could be a great help there and in other communities like it. The more involvement the faster Wine will reach the 1.0 level.

2 1

Assertion fails in riched20; relay debug segfaults
by Adrian Harvey 09 May '05

09 May '05

The wine version of riched20 fails an assertion when starting StreamboxVCR $ wine .wine/drive_c/Program\ Files/StreamboxVcrSuite2/StreamBoxVCR1Beta31/vcr_31turbo.exe fixme:ole:CoRegisterMessageFilter stub fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33- b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 err:ole:ITypeInfo_fnInvoke did not find member id fffffdfa, flags 4! err:ole:ITypeInfo_fnInvoke did not find member id fffffdfb, flags 4! fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub wine-pthread: run.c:522: ME_CalcRunExtent: Assertion `size.cx' failed. fixme:ole:ITypeInfo_fnRelease destroy child objects Along with a popup dialogue box from the visual C++ runtime library indicating abnormal program termination. The file run.c appears to be part of riched20, and indeed overriding the load order to native only for that DLL allows the program work. All reasonably standard debugging so far, and I went for some more logging to aid tracing the problem (or to log in bugzilla when it all gets too hard for my skill level ;-) ) $ WINEDEBUG="+relay" wine .wine/drive_c/Program\ Files/StreamboxVcrSuite2/StreamBoxVCR1Beta31/vcr_31turbo.exe 0009:Call kernel32.__wine_kernel_init() ret=55727d9e Segmentation fault Shortest relay trace I've ever had! But I'm not really sure where to go from here... Running GDB on it gives me no useful results. I have an AMD64 box running Fedora Core 3 and wine is the latest from CVS. I'm going to try some other tracing to look at the riched problem, but +relay crashing seems serious to me. Adrian

4 8

Quicken/CreateCompatibleBitmap issue revisited
by Carl Sopchak 09 May '05

09 May '05

In the bug found at http://bugs.winehq.org/show_bug.cgi?id=2096 , I have described an issue that I am having with Quicken Deluxe 2000 when running under Wine. The symptom is that Quicken was crashing HARD when trying to print a partial page of checks on a laser printer. Now, I just get fixme's stating that CreateCompatibleBitmap is getting bad parameters. (In lieu of reading the following, you could probably just read the last few posts in bugzilla for this bug...) Long story short, with the help of some others (thanks guys!), it seems that CreateCompatibleBitmap is being called directly from Quicken, and that Quicken seems to be passing an address instead of a value for the height parameter. Now, I would normally just mark the bug as INVALID, and let it go. But, while looking into things, I read the MSDN page describing the function of CreateCompatibleBitmap, and it appears to me that there may be "issues" with Wine's implementation of CreateCompatibleBitmap. To quote my post attached to the bug: "I would have changed this bug entry's resolution to INVALID, except that (a) I wouldn't mind a more knowledgeable (of Wine, Win API, and C) person to verify my findings, and, more importantly, (b) it seems to me that Windows would be handling this scenario differently than Wine (or Intuit/Quicken would have some customer relations problems due to frequent crashes) - should Wine do something different when the parameters are out of whack? The only thing I can see on MSDN under CreateCompatibleBitmap is "Windows 95/98/Me: The created bitmap cannot exceed 16MB in size." "Which I guess brings up another point... dlls/gdi/bitmap.c's CreateCompatibleBitmap shows the aforementioned fixme message if the width or height exceeds 0x10000, and no bitmap is returned. This seems wrong to me on three counts: (1) MSDN states that if either width or height is zero, a 1x1 monochrome bitmap is returned (in my case the height was 0, but the width was "huge", so a 1x1 bitmap should be returned); (2) a 0x11000 by 0x2 bitmap is within the (more restrictive Win95) 16 MB limit and should be valid; and (3) Win NT/2000/XP do not seem to have any restriction on a bitmap's size (except physical and paged memory constraints), so at least in theory, any values for width and height are "valid". So, this begs the question, should Wine's CreateCompatibleBitmap be modified for any (or all?) of the reasons above? Thoughts? Comments? Carl

3 3

Bugs out of my league
by Dustin Navea 08 May '05

08 May '05

Bug 2938: Seemed at first like this was due to the recent patch to get Mozilla/FF installers working, but after he reverted to the Feb release and the problem still existed, it must be something else.. Bug 2919: If I am reading the backtrace right, it looks like the installer is crashing in kernel32, but then again it does the same for the quicktime installer on the same cd, so could it be configuration related? Just need someone to take a look and comment here, and I'll take care of em, until I need a patch anyways lol. Dustin

1 0

Now hiring
by Dustin Navea 08 May '05

08 May '05

Jeremy, guys, it seems we have run low on "official" janitors, I have talked with someone that seems to know what they are doing as far as the right way to bug report (he contribs to MPlayer), and he said he would be willing to help maintain bugzilla, but that he doesn't have a whole lot of time, the extra hand will be helpful. Could you add 'canconfirm' and 'editbugs' to inverseparadox(a)comcast.net? Does anyone have any objection to me posting a note on wine-users that we are accepting applications for dedicated bug maintainers (read: janitors lol)? I will handle "interviewing and hiring", and just send an email to Jeremy when we get people that know what they are doing and can really be of use.. I think 5 should be good for now.. Dustin

2 2

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