May 2005 - Wine-devel - list.winehq.org

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 13 May '05

13 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 13 May '05

13 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