wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: Extending File Dialog to include unix file paths [4/4]
by Steven Edwards 13 May '05

13 May '05

Hi Michael, I really like the idea of trying to tie the apps in better for users of Winelib applications but I have a few problems. (I should have spoken up when the first of the Unixfs stuff was going in to shell32 because I feel it should have been a shellext outsite of shell32 but now I am off the subject) --- Michael Lin <mlin(a)corvu.com.au> wrote: --- dlls/commdlg/comdlg32.spec +@ stdcall UnixFSGetOpenFileNameA(ptr) +@ stdcall UnixFSGetOpenFileN Is there anyway for us to have these functions inlined or something rather than exported all the time is there? The reason I ask is that being able to build applications using Wine on Windows and Mingw helps with testing and if we building on Windows using Wine headers and link to the Wine import libs the application will fail running the application on Windows because the Windows dll wont export these functions. +BOOL WINAPI UnixFSGetSaveFileNameW( + LPOPENFILENAMEW ofn) /* [in/out] address of init structure */ +{ + BOOL win16look = FALSE; + + if (ofn->Flags & (OFN_ALLOWMULTISELECT|OFN_ENABLEHOOK|OFN_ENABLETEMPLATE)) + win16look = (ofn->Flags & OFN_EXPLORER) ? FALSE : TRUE; + + if (win16look) + return GetFileName31W(ofn, SAVE_DIALOG); + else You should not need any of this for a Winelib app. Office97 does this where it creates a 32bit dialog with a Win16 look and its needed for backwards compatiblity only. No new application should depend on this behavior and clearly not one that you have the source code to in Winelib. I already broke this in Wine once. Just return GetFileDialog95W. + return GetFileDialog95W(ofn, SAVE_DIALOG, TRUE); } Thanks Steven Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html

2 1

ERROR_NOT_READY (21) in ne_module.c
by Felix Nawothnig 13 May '05

13 May '05

Since bug 2131 was closed I'll paste it here again: ne_module.c explicitly sets errorcode 21 (ERROR_NOT_READY) when ( LoadLibraryA()ing the owner of a 16bit dll failed or the search for the 16bit dll returned a real (.so) dll and not a symlink to the owner ) and trying to load a native version of the 16bit dll failed with ERROR_FILE_NOT_FOUND. (dlls/kernel/ne_module.c:1218) Anyone knows the reason for that behavior? -flx

3 5

Re: Support for binaries that were abandoned by M$, and maintenance hell?
by Steven Edwards 13 May '05

13 May '05

--- Francois Gouget <fgouget(a)free.fr> wrote: > Furthermore a lot of '32bit applications' actually use 16bit code either > directly or indirectly (although that may be getting less common these > days). What this means is that if you remove 16bit support it's quite > likely a lot of 32bit applications will stop working. I do wish we could change it though. We could share more code with ReactOS with less hassle on merges if we could figure out a way to split the Win16 code out better for say the edit control. Thanks Steven Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/

1 0

Re: [?? Probable Spam] user32.dll Add redraw and WM_WINDOWPOS* notifications to SetActiveWindow [1]
by Dmitry Timoshkov 13 May '05

13 May '05

"Vitaliy Margolen" <wine-patch(a)kievinfo.com> wrote: > According to native messages sent to app we should redraw window > inside SetActiveWindow. If you have a test app then it should be converted into a Wine message test, there is no other way to prove that your patch is correct. > @@ -152,7 +232,7 @@ static BOOL set_active_window( HWND hwnd > > if (IsWindow(hwnd)) > { > - SendMessageW( hwnd, WM_NCACTIVATE, (hwnd == GetForegroundWindow()), (LPARAM)previous ); > + SendMessageW( hwnd, WM_NCACTIVATE, TRUE, (LPARAM)previous ); Active and foreground windows in win32 are not necessary the same window. -- Dmitry.

3 4

Support for binaries that were abandoned by M$, and maintenance hell?
by Dustin Navea 12 May '05

12 May '05

The discussion on 16-bit support for cards.dll led me to an interesting theory. If the big name vendors are dropping support for 16-bit programs, they must be doing it for a reason, right? The only reason I can come up with is because they dont have the resources (or maybe just the desire) to maintain 2 separate trees (1 16-bit and 1 32-bit), and soon to be 3 trees including 64-bit.. We have the desire to allow any windows program to run, whether it runs in a current version of windows or not. The problem with this is that over time, dos support has faded damatically, as well as win16 support. Soon we will start writing more win64 conformance code, and less win32. Where will that leave all of the people that dont jump on the 64-bit bandwagon any time soon? <flame war first shot> I think we are getting to that point, from a maintenance perspective, where we should seriously consider reorganizing the project into a more hierarchal (sp?) structure, where we have some people that can take some time off from contributing 32 or 64-bit code when need be, to contribute some 16-bit code for a user who wants to use an older program. Possibly (just an idea) we should make a dedicated project page on sourceforge specifically for 16-bits. As I said, soon we will be not necessarily abandoning 32-bits, but writing more 64-bits.. Sure we have separation to keep things apart, but wine is starting to get loaded down with things that only a small minority of users need anymore.. Perhaps it is time (just another idea) to copy out the 16-bit code into it's own project? That way we can organize things more efficiently, and at the same time, reduce 1) download time of wine, and 2) compile time. Of course, we would still leave 16-bit support in the main project, but we would no longer maintain it there.. We could maintain it in wine16.... </flame war first shot> Comments? Suggestions? Flames??? Bring it ;-) Dustin

4 3

Bug 2931 (again)
by Dustin Navea 12 May '05

12 May '05

Ok, the author has posted a link to the commit.. http://www.winehq.org/hypermail/wine-cvs/2004/10/0376.html Seems to be what broke it, per regression testing. I dunno if this maybe caused a bug somewhere else to show up or what, but I figure someone could look at it.. Dustin

5 8

CVS compilation problem
by Uwe Bonnes 12 May '05

12 May '05

Hallo, I updated yesterday and today. Compiling with todays CVS gives: ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole joystick.o keyboard.o mouse.o testlist.o -o dinput_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../dlls/dinput -L../../../dlls/ole32 -L../../../dlls/version -L../../../dlls/user32 -L../../../dlls/kernel32 -L../../../libs -ldinput -lole32 -lversion -luser32 -lkernel32 -ldxguid -luuid -ldxerr8 joystick.o(.text+0x543): In function `EnumJoysticks': /spare/bon/wine-realclean/wine/dlls/dinput/tests/joystick.c:165: undefined reference to `c_dfDIJoystick' joystick.o(.text+0x592):/spare/bon/wine-realclean/wine/dlls/dinput/tests/joystick.c:169: undefined reference to `c_dfDIJoystick2' collect2: ld returned 1 exit status 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 2

Re: info please part 2
by Dustin Navea 12 May '05

12 May '05

juan melgarejo wrote: > Is there any document or how-to showing: > how to run a backtrace using the wine debugger > how set debug parameters for wine tracing of program execution > how to submit bugs to bugzilla (how to report, content) > How to Know proper settings for bugs > (when a bug should be a blocker, which bug depends on which other bug, > etc) ? I should mention that the wine documentation is somewhat out of date, so generally if you don't already know how to do the things mentioned above, they will give you a rough idea, but some of the parameters have changed (especially on setting debug flags for tracing). While you can still apply, the users who already know how to do the above will obviously have a greater chance to be recruited. Dustin

1 0

Re: info please
by Dustin Navea 12 May '05

12 May '05

juan melgarejo wrote: > Is there any document or how-to showing: > how to run a backtrace using the wine debugger > how set debug parameters for wine tracing of program execution > how to submit bugs to bugzilla (how to report, content) > How to Know proper settings for bugs > (when a bug should be a blocker, which bug depends on which other bug, > etc) ? > > Regards, > Juan > The Wine FAQ at http://winehq.org/site/docs/wine-faq/index The Wine User Guide at http://winehq.org/site/docs/wine-user/index The Wine Developers Guide at http://winehq.org/site/docs/wine-devel/index How to help get applications working in Wine at http://winehq.org/site/helping-applications Getting Started with Wine Development at http://winehq.org/site/developer-cheatsheet Those are the best resources. You can also check the wine wiki (although I don't have the address).. Dustin

1 0

Re: Installing Acrobat Reader 7 and Acrobat in general
by gslink 12 May '05

12 May '05

Use the native Linux Reader 7 from the Adobe web site. Running Reader 7 under Wine isn't worth the trouble. Acrobat Professional is a different matter. The latest Acrobat Professional that will work on Wine is 5. Both 6 and 7 require dlls that must be supplied from Windows. Seven has copy protect features that actually discourage use on any machine. With some trouble you can probably get 6 to work. It will currently install and with the addition of the missing dlls almost work. If someone wants to patch Wine so that 6 runs it would probably see considerable use.

1 0

Now Recruiting
by Dustin Navea 12 May '05

12 May '05

Please do not reply to this email with this same subject line unless you are notifying myself that you would like to have an interview. If you need to discuss this more with me, use a subject of "Discuss - Now Recruiting" Attention all users of wine! Have you ever run into a situation where "it worked before, but now it doesnt"? Have you ever wanted to help out the wine project, but either don't know how to program, or don't know how to get started? Have you reported bugs on bugs.winehq.com and gotten frustrated because of the response time? You are not alone! The Wine Project is proud to announce that we are now recruiting for Maintainer/Janitor positions on the Bugzilla Database! Bugzilla Maintainers should: Have a good working knowledge of Linux Know how to run a backtrace using the wine debugger Know how set debug parameters for wine tracing of program execution Know how to submit bugs to bugzilla Know proper settings for bugs (when a bug should be a blocker, which bug depends on which other bug, etc) Have strong interpersonal communication skills, and outstanding customer service skills Programming knowledge/experience is a BIG Plus, but is not required Being able to set aside a minimum of 7 hours a _week_ to work on bugs is a BIG Plus, but is not required This position is for the most part unsupervised, and strictly voluntary, meaning you will not be compensated/paid in any way. An interview does not create any form of contract either express or implied between you and The Wine Project, nor any of it's developers, contributors, subsidiaries, sister projects, or other users. If you feel that you have what it takes, and would like to apply, please reply to this message, and send it to Dustin Navea (Speeddymon at gmail dot com) Thanks and good luck! Wine Developers

1 0

Re: comctl32: Make sure all msg's are dispatched while tracking a WM_LBUTTONDOWN msg
by Rein Klazes 12 May '05

12 May '05

On Thu, 12 May 2005 02:59:38 -0500, you wrote: > Hey, > > This is a patch for the WM_LBUTTONUP msg problem, but I've taken the > advice of Dmitry and now all messages are dispatched. > > Changelog > * Make sure all msg's are dispatched while tracking a WM_LBUTTONDOWN msg. Patches like this have been proposed before. They are wrong: Windows *does* eat the WM_LBUTTONUP in the mouse track message loop. There are cases when in Wine this mouse tracking is entered, where they are not under Windows thus causing loss of messages. http://www.winehq.org/hypermail/wine-devel/2004/05/0159.html http://www.winehq.org/hypermail/wine-devel/2004/09/0072.html Rein.

1 0

Re: comctl32: Make sure a WM_LBUTTONUP msg is dispatched while after a WM_LBUTTONDOWN msg
by Dmitry Timoshkov 12 May '05

12 May '05

"James Hawkins" <truiken(a)gmail.com> wrote: > You were right about having the NM_CLICK msg sent in > LISTVIEW_LButtonUp, and the problem was that a WM_LBUTTONUP msg was > never sent. This fixes the problem where you had to double click an > item in the drives list to select it. > > Changelog > * Make sure a WM_LBUTTONUP msg is dispatched after tracking a WM_LBUTTONDOWN msg > --- dlls/comctl32/listview.c 6 May 2005 15:44:32 -0000 1.409 > +++ dlls/comctl32/listview.c 12 May 2005 05:04:06 -0000 > @@ -7948,6 +7948,9 @@ static LRESULT LISTVIEW_TrackMouse(LISTV > else if (msg.message >= WM_LBUTTONDOWN && > msg.message <= WM_RBUTTONDBLCLK) > { > + if (msg.message == WM_LBUTTONUP) > + DispatchMessageW(&msg); Why WM_LBUTTONUP should be different from other kinds of messages? I.e. why all messages could not be passed to DispatchMessage? What if just move DispatchMessageW call right right after PeekMessageW? -- Dmitry.

2 1

Getting rid of LOCAL_ exports
by Dimi Paun 12 May '05

12 May '05

>From a cursory look at the problem, it seems we can turn things upside down. Right now LOCAL_*() functions (Wine specific) are equivalent to the Local*16() functions (Windows exports), with the exception that they take a selector as first argument (which makes them more general). As a result, Local*16() functions are implemented on top of the LOCAL_*() ones. This is only half of the story. In fact, the Local*16() functions do take the segment as input, but in a more awkward manner: as the value of the DS register. So we can actually implement the LOCAL_*() functions on top of the Local*16() ones by messing with the DS register. Doing so would hopefully get rid of the LOCAL_*() exports from kernel. I've taken a stab (prototype level) at the LOCAL_Alloc() function (patch included below). Would such an approach be acceptable? Index: include/local.h =================================================================== RCS file: /var/cvs/wine/include/local.h,v retrieving revision 1.6 diff -u -p -r1.6 local.h --- include/local.h 28 Aug 2003 21:43:35 -0000 1.6 +++ include/local.h 10 May 2005 18:20:03 -0000 @@ -23,12 +23,22 @@ #include <windef.h> #include <wine/windef16.h> +#include <stackframe.h> /* These function are equivalent to the Local* API functions, */ /* excepted that they need DS as the first parameter. This */ /* allows managing several heaps from the emulation library. */ +static inline HLOCAL16 LOCAL_Alloc( HANDLE16 ds, UINT16 flags, WORD size ) +{ + HANDLE16 oldDS = CURRENT_DS; + HLOCAL16 ret; + + CURRENT_DS = ds; + ret = LocalAlloc16 (flags, size); + CURRENT_DS = oldDS; + return ret; +} -extern HLOCAL16 LOCAL_Alloc( HANDLE16 ds, UINT16 flags, WORD size ); extern HLOCAL16 LOCAL_ReAlloc( HANDLE16 ds, HLOCAL16 handle, WORD size, UINT16 flags ); extern HLOCAL16 LOCAL_Free( HANDLE16 ds, HLOCAL16 handle ); Index: dlls/kernel/kernel32.spec =================================================================== RCS file: /var/cvs/wine/dlls/kernel/kernel32.spec,v retrieving revision 1.148 diff -u -p -r1.148 kernel32.spec --- dlls/kernel/kernel32.spec 10 May 2005 15:22:10 -0000 1.148 +++ dlls/kernel/kernel32.spec 10 May 2005 18:22:10 -0000 @@ -1167,7 +1167,6 @@ # Wine dll separation hacks, these will go away, don't use them # @ cdecl DOSMEM_AllocSelector(long) -@ cdecl LOCAL_Alloc(long long long) @ cdecl LOCAL_Compact(long long long) @ cdecl LOCAL_CountFree(long) @ cdecl LOCAL_Free(long long) Index: dlls/kernel/local16.c =================================================================== RCS file: /var/cvs/wine/dlls/kernel/local16.c,v retrieving revision 1.10 diff -u -p -r1.10 local16.c --- dlls/kernel/local16.c 24 Mar 2005 21:01:38 -0000 1.10 +++ dlls/kernel/local16.c 10 May 2005 17:56:15 -0000 @@ -1150,15 +1150,13 @@ HLOCAL16 LOCAL_Free( HANDLE16 ds, HLOCAL /*********************************************************************** - * LOCAL_Alloc - * - * Implementation of LocalAlloc(). - * + * LocalAlloc (KERNEL.5) */ -HLOCAL16 LOCAL_Alloc( HANDLE16 ds, WORD flags, WORD size ) +HLOCAL16 WINAPI LocalAlloc16( UINT16 flags, WORD size ) { + HANDLE16 ds = CURRENT_DS; + HLOCAL16 handle = 0; char *ptr; - HLOCAL16 handle; TRACE("%04x %d ds=%04x\n", flags, size, ds ); @@ -1171,7 +1169,7 @@ HLOCAL16 LOCAL_Alloc( HANDLE16 ds, WORD if(size) { if (!(hmem = LOCAL_GetBlock( ds, size + MOVEABLE_PREFIX, flags ))) - return 0; + goto exit; } else /* We just need to allocate a discarded handle */ hmem = 0; @@ -1180,7 +1178,7 @@ HLOCAL16 LOCAL_Alloc( HANDLE16 ds, WORD WARN("Couldn't get handle.\n"); if(hmem) LOCAL_FreeArena( ds, ARENA_HEADER(hmem) ); - return 0; + goto exit; } ptr = MapSL( MAKESEGPTR( ds, 0 ) ); plhe = (LOCALHANDLEENTRY *)(ptr + handle); @@ -1199,10 +1197,11 @@ HLOCAL16 LOCAL_Alloc( HANDLE16 ds, WORD } else /* FIXED */ { - if(!size) - return 0; - handle = LOCAL_GetBlock( ds, size, flags ); + if(size) handle = LOCAL_GetBlock( ds, size, flags ); } + +exit: + CURRENT_STACK16->ecx = handle; /* must be returned in cx too */ return handle; } @@ -1595,17 +1594,6 @@ HLOCAL16 LOCAL_Handle( HANDLE16 ds, WORD /*********************************************************************** - * LocalAlloc (KERNEL.5) - */ -HLOCAL16 WINAPI LocalAlloc16( UINT16 flags, WORD size ) -{ - HLOCAL16 ret = LOCAL_Alloc( CURRENT_DS, flags, size ); - CURRENT_STACK16->ecx = ret; /* must be returned in cx too */ - return ret; -} - - -/*********************************************************************** * LocalReAlloc (KERNEL.6) */ HLOCAL16 WINAPI LocalReAlloc16( HLOCAL16 handle, WORD size, UINT16 flags ) -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

2 1

Installing Adobes Acrobat Reader 7.0 (Windows XP Version I think)
by Peter 12 May '05

12 May '05

Hello, I try to install the Adobes Acrobatreader 7.0. Now this didn't work it gave me a quite odd message that an unexpected error occured with a long number. I tried to run wine with the debug Variable +all. I never done this before so can anybody help me? Is the ntdll missing something or is it an bug? thx in advance Peter winedebug geave me at the same point this: 0009:Ret PE DLL (proc=0x7f510000,module=0x7f500000 L"imm32.dll",reason=PROCESS_ DETACH,res=0x1) retval=1 0009:Call PE DLL (proc=0x76de7698,module=0x76de0000 L"gdi32.dll",reason=PROCESS_ DETACH,res=0x1) 0009:Call kernel32.__wine_unregister_dll_16(76e39680) ret=76de7872 0009:Ret kernel32.__wine_unregister_dll_16() retval=00000007 ret=76de7872 0009:Call kernel32.__wine_unregister_dll_16(76e39698) ret=76deaa02 0009:Ret kernel32.__wine_unregister_dll_16() retval=00000008 ret=76deaa02 0009:Call kernel32.__wine_unregister_dll_16(76e396b0) ret=76deace2 0009:Ret kernel32.__wine_unregister_dll_16() retval=00000009 ret=76deace2 0009:Ret PE DLL (proc=0x76de7698,module=0x76de0000 L"gdi32.dll",reason=PROCESS_ DETACH,res=0x1) retval=1 0009:Call PE DLL (proc=0x7705ebd0,module=0x77050000 L"advapi32.dll",reason=PROCE SS_DETACH,res=0x1) 0009:Ret PE DLL (proc=0x7705ebd0,module=0x77050000 L"advapi32.dll",reason=PROCE SS_DETACH,res=0x1) retval=1 0009:Call PE DLL (proc=0x77b02f00,module=0x77af0000 L"kernel32.dll",reason=PROCE SS_DETACH,res=0x1) 0009:Call ntdll.RtlEnterCriticalSection(77bde5c0) ret=77b4e3e5 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=77b4e3e5 0009:Call ntdll.RtlLeaveCriticalSection(77bde5c0) ret=77b4e3f5 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=77b4e3f5 0009:Ret PE DLL (proc=0x77b02f00,module=0x77af0000 L"kernel32.dll",reason=PROCE SS_DETACH,res=0x1) retval=1 0009:Call PE DLL (proc=0x77eb535c,module=0x77ea0000 L"ntdll.dll",reason=PROCESS_ DETACH,res=0x1) 0009:Ret PE DLL (proc=0x77eb535c,module=0x77ea0000 L"ntdll.dll",reason=PROCESS_ DETACH,res=0x1) retval=1 0009:Ret ntdll.LdrShutdownProcess() retval=00000000 ret=77b484a2 0009: terminate_process( handle=0xffffffff, exit_code=1150 ) 0009: terminate_process() = 0 { self=1 } 0009: *killed* exit_code=1150

2 1

Re: msvcrt: implement signals, take 2
by Alexandre Julliard 12 May '05

12 May '05

Juan Lang <juan_lang(a)yahoo.com> writes: > + switch (sig) > + { > + /* Cases that fall through to signal(2) */ > + case SIGABRT: > + case SIGFPE: > + case SIGILL: > + case SIGSEGV: > + ret = signal(sig, func); > + break; You can't do that, this will cause major trouble. MSVCRT signals should be generated from Win32 exceptions. -- Alexandre Julliard julliard(a)winehq.org

1 0

RE: tools/widl
by Ge van Geldorp 12 May '05

12 May '05

I'm wondering what happened to the reworked widl patch at http://www.winehq.org/hypermail/wine-patches/2005/04/0371.html? It hasn't been applied yet, does that mean there's no interest on the Wine side and I can drop it from my TODO list? Best regards, Ge van Geldorp.

2 1

Re: user32.dll fix and test ShowOwnedPopups
by Dmitry Timoshkov 12 May '05

12 May '05

"Vitaliy Margolen" <wine-patch(a)kievinfo.com> wrote: > ShowOwnedPopups should handle none WS_POPUP style windows as well. > And actually show/hide windows. > Match names for WM_SHOWWINDOW status codes to MSDN > @@ -2701,6 +2701,7 @@ BOOL WINAPI ShowOwnedPopups( HWND owner, > * regardless of the state of the owner > */ > SendMessageW(win_array[count], WM_SHOWWINDOW, SW_SHOW, SW_PARENTOPENING); > + ShowWindow(win_array[count], SW_SHOW); > continue; > } > } > @@ -2715,6 +2716,7 @@ BOOL WINAPI ShowOwnedPopups( HWND owner, > * regardless of the state of the owner > */ > SendMessageW(win_array[count], WM_SHOWWINDOW, SW_HIDE, SW_PARENTCLOSING); > + ShowWindow(win_array[count], SW_HIDE); Then each owned window will receive 2 WM_SHOWWINDOW messages. Are you sure that Windows does it that way? I'd advise to write a message test to verify it. -- Dmitry.

2 2

[Bug 2932] - copy / paste to openoffice
by Dustin Navea 12 May '05

12 May '05

Basically, before 01/11/05, copying and pasting to OO worked, and after said date, it doesn't. The Bug is at: http://bugs.winehq.org/show_bug.cgi?id=2932 The patch causing it is at: http://www.winehq.org/hypermail/wine-cvs/2005/01/0276.html It looks like the patch removed W->A calls from the clipboard code. All other relevant information is posted in the bug Dustin

2 1

Borland software patent restricting Wine development
by Ingrid Marson 12 May '05

12 May '05

I'm writing an article today following Dimitri O. Paun's talk at the Wine Developer conference in Stuttgart. He said that Winelib development is restricted due to a Borland software patent. Borland's software patent means that an important feature to the Gnu Compiler Collection project cannot be applied. Winelib support would depend on that patch. The FFII has written an article on this: http://wiki.ffii.org/WineConf050501En I am keen to find out more about this issue. Does anyone know about this issue, or know how I can contact Dimitri? (I have tried to find his email address using Google but haven't had any success). Thanks for your help. Regards, Ingrid Ingrid Marson Reporter ZDNet UK www.zdnet.co.uk T: +44 (0)20 7903 6835

3 2

Wine test question: How to test for messages send?
by Tobias Burnus 12 May '05

12 May '05

Hello, I'm trying to write a conformance test for user/edit.c: EDIT_EM_ReplaceSel(). While I figured out how to send messages, call functions etc. I don't know how to check whether a message has been sent. But I need to know whether Windows sends one as a EDIT_NOTIFY_PARENT(es, EN_MAXTEXT, "EN_MAXTEXT") causes my Origin to crash. Background: Origin crashes since a patch was introduced in Wine which sends this message. Origin (at least under Wine) seems to create a 7px wide edit control which is then trys to fill with "10" (being 20px wide). Since not even "1" fits in there, the content of the edit control is "" and a EN_MAXTEXT is sent. While removing the EDIT_NOTIFY_PARENT line helps, this is surely not the right solution; Lauri Tulmin (author of mentioned patch) suggested to test for it: "From what I understand, the program crashes when it receives EN_MAXTEXT notification. You should figure out why the textbox is too small to contain the text. Or maybe this notification shouldn't be sent at all, although MSDN says it should be, but maybe there are some exceptions. Probably you'll need to write some test's to figure out what exactly goes wrong." For details, see bug 2813. http://bugs.winehq.org/show_bug.cgi?id=2813 Tobias

2 1

SEH and gcc again
by Daniel Kegel 11 May '05

11 May '05

The old SEH / gcc question came up again on the gcc mailing list; see http://gcc.gnu.org/ml/gcc/2005-05/msg00511.html and followups. If anyone has anything constructive to add to that thread, this is a good chance to get the story right before it shows up on ZDNet.

1 0

Looking for win9x/ME testers
by Stefan Leichter 11 May '05

11 May '05

Hello, the ole32 tests are working now for WinNT again: But they do not load on win9x/ME. Can someone with a Win9x/ME system run ole32_test.exe manualy and report the text displayed in the message box when it is started. ole32_test.exe is included in winetest-latest.exe. You can download winetest-latest.exe from http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/ You will find ole32_test.exe in c:\temp\wct when the tests are performed. Thanks for your help Stefan

2 1

Flattening of ddraw directory and renaming of files
by Christian Costa 11 May '05

11 May '05

Hi, I plan to flatten the ddraw directory and perform some files renaming in it. The changes I'm thinking about are in the attached file. If you have suggestions (or objections), let me know. If this is ok, I plan to submit the changes soon. Bye, Christian struct_convert.c \ convert.c -> ddraw_utils.c helper.c / d3dexecutebuffer.c -> executebuffer.c d3dmaterial.c -> material.c d3dvertexbuffer.c -> vertexbuffer.c main.c -> * regsvr.c -> * d3dcommon.c -> d3d_utils.c d3dlight.c -> light.c d3dtexture.c -> texture.c d3dviewport.c -> viewport.c mesa.c -> opengl.c d3d_private.h -> * ddcomimpl.h -> * ddraw_private.h -> * gl_api.h -> * gl_private.h -> * mesa_private.h -> opengl_private.h d3ddevice/main.c -> device_main.c d3ddevice/main.h -> device_main.h d3ddevice/mesa.c -> device_opengl.c dclipper/main.c -> clipper.c dclipper/main.h -> clipper.h ddraw/hal.c -> ddraw_hal.h ddraw/hal.h -> ddraw_hal.c ddraw/main.c -> ddraw_main.c ddraw/main.h -> ddraw_main.h ddraw/thunks.c -> ddraw_thunks.c ddraw/user.c -> ddraw_user.c ddraw/user.h -> ddraw_user.h direct3d/main.c -> direct3d_main.c direct3d/main.h -> direct3d_main.h direct3d/mesa.c -> direct3d_opengl.c dpalette/hal.c -> palette_hal.c dpalette/hal.h -> palette_hal.h dpalette/main.c -> palette_main.c dpalette/main.h -> palette_main.h dsurface/dib.c -> surface_dib.c dsurface/dib.h -> surface_dib.h dsurface/fakezbuffer.c -> surface_fakezbuffer.c dsurface/fakezbuffer.h -> surface_fakezbuffer.h dsurface/gamma.c -> surface_gamma.c dsurface/hal.c -> surface_hal.c dsurface/hal.h -> surface_hal.h dsurface/main.c -> surface_main.c dsurface/main.h -> surface_main.h dsurface/thunks.c -> surface_thunks.c dsurface/thunks.h -> surface_thunks.h dsurface/user.c -> surface_user.c dsurface/user.h -> surface_user.h dsurface/wndproc.c -> surface_wndproc.c dsurface/wndproc.h -> surface_wndproc.h Note: * = no change

5 9

Re: [QCAP] patch 3, Adding enumMediaType object
by Robert Shearman 11 May '05

11 May '05

Rolf Kalbermatter wrote: >Changelog > - dlls/qcap/Makefile.in > - dlls/qcap/qcap_main.h > dlls/qcap/enummedia.c > Add IEnumMediaType object for use by other class objects. This is >taken > from quartz with only minor adaptions. > > We should be putting these files into a static library that we can link to from quartz, qcap & other DirectShow dependent DLLs. Rob

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