- Wine-Devel - list.winehq.org

Re: Installing Acrobat Reader 7 and Acrobat in general
by gslink May 13, 2005

May 13, 2005

Peter wrote: > I see. > Of course I have Acrobat 7 installed. The problem is Adobe does not > supply the DRM plugin (Yea I know some of you do not like DRM and I have > too some reservations but we should have the choice, shouldn't we?) > Since the only other way to get DRM support beside wine is VMware wich > is more ugly to set up. > > I would like to have a working Acrobat reader with DRM support on wine > since this is less trouble (and more efficent) then the VMware solution > people use atm. > > Maybe I can get Acrobat reader 5 with DRM support up and running. > Adobe has a very confusing policy of giving away information what > Version can on which Plattform. > I send them a note already but i fear (like always) I am ignored. :( > > cheers > Peter > > Am Donnerstag, den 12.05.2005, 11:46 -0400 schrieb gslink: > >>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. >> > > > The only difference between talking to a telephone pole and talking to Adobe is that if you drink enough the telephone pole will answer. In reality almost nothing of any importance currently runs on Wine without some setup. What you probably need to do is to experiment with replacing some of the dlls or adding some from Windows. This is usually what is necessary. You may also need to install the software in a Windows machine and then copy it over. Start trying things and something will probably work. I have been getting on the Wine people because this feature of Wine makes it useless for the average user. There needs to be some easy way for someone to report what is necessary to get a new version of something running or there needs to be a good configurator written. Wine is a very good program but the Wine group is making a classic programming error in forgetting the user interface. It doesn't make any difference how good it is if you can't get at it! In this case you can't.

2 1

Re: Looking for win9x/ME testers
by Saulius Krasuckas May 13, 2005

May 13, 2005

* On Thu, 12 May 2005, Hans Leidekker wrote: > * On Thursday 12 May 2005 00:14, Kevin Koltzau wrote: > > The ole32_test.exe file is linked to missing export NTDLL.DLL:atoi. > > This patch fixes it. ... > Changelog: > Don't import from ntdll. Can someone explain me, please, where would atoi() function be linked now to? I still have not installed MinGW package, so cannot cross-compile winetest and cannot check this myself. :-/

2 1

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

May 13, 2005

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 May 13, 2005

May 13, 2005

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 May 13, 2005

May 13, 2005

--- 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 May 13, 2005

May 13, 2005

"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 May 12, 2005

May 12, 2005

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 May 12, 2005

May 12, 2005

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 May 12, 2005

May 12, 2005

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 May 12, 2005

May 12, 2005

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