January 2004 - Wine-Devel - list.winehq.org

Re: NHL 2004 Testing Report

by Tom

Abdul-Haseeb Ahmad wrote: > Jonathan Wilson wrote: > >> Abdul-Haseeb Ahmad wrote: >> >>> ive tinkered around some more, and i copied over winxp's >>> kernel32.dll, and i >> >> >> You cant use kernel32.dll from real windows on WINE. >> >> >> > if i do put it there, the program goes past the kernel32 error, as i've > explained.. i changed it to a dummy kernel32 and it worked as well > > Have you tried NHL 2003, 2002, 2001, 99 ?

Jan. 29, 2004

Re: WineHQ: Isn't status update news?

by Dmitry Timoshkov

"Tom" <twickline(a)skybest.com> wrote: > The only thing left is the WWN articles on two pages. You can send the patch > or you can send them to me and ill do the merge. I'd suggest to do the following changes in the Multimedia/mciavi section: Remove * Synchronization This one should be done already. Remove * Replace AVI file parser by using API from avifil32 This is not such a complex task and it works perfectly now. Native mciavi doesn't use AVI parsing APIs from avifil32 either. -- Dmitry.

Jan. 29, 2004

Help needed to build & run a VC++ program in Linux

by saravanan

Hi, I want to know how i can a compile & port a simple VC++ application to linux using wine. I tried to compile a VC++ application using the winelib method. But it showed a lot of errors. Does anyone have any idea. I had tried all options. I had done follwing things 1) I created a simple VC++ application. Just to display a msg on clicking a button. 2) I copied it to Linux' home directory 3) I executed following commands a)winemaker --lower-uppercase . (later i tried the follwing command also. winemaker --lower-uppercase --console -I/usr/include/include/wine -L/usr/include/include/wine .) ///To the /usr/include/include directory i copied all the original MFC files from V.Studio. b) ./configure --with-wine-includes=/usr/include/include now it showed the error --> checking for -lmfc... configure: error: Could not find the MFC library I couldn't able to correcet it. Where i can get the original -lmfc (libmfc) file, there is no such file present in the system. c)Finally I myself created a fake libmfc.so file and placed it in the /usr/include/include directory. But when i "make" it showed a lot of errors . Some are given below . ---------- s/usr/include/include/afxwin1.inl:1014: warning: ISO C++ forbids declaration of `operator==' with no type /usr/include/include/afxwin1.inl:1016: warning: ISO C++ forbids declaration of `operator!=' with no type . . /usr/include/include/afxole.inl:97: `vt' undeclared (first use this function) /usr/include/include/afxole.inl:97: (Each undeclared identifier is reported only once for each function it appears in.) /usr/include/include/afxole.inl: In method `COleVariant::COleVariant (unsigned char)': . . /usr/include/include/afxole.inl: In method `COleCurrency::COleCurrency ()': /usr/include/include/afxole.inl:123: `union tagCY' has no member named `Hi' /usr/include/include/afxole.inl:123: `union tagCY' has no member named `Lo' /usr/include/include/afxole.inl:283: `parray' undeclared (first use this function) make: *** [vctest.o] Error 1 ------ Later I run the command winemaker --lower-uppercase . in the /usr/include/include directory and converted entire contents. after that when i make the vc++ application again it showed some different errors. -------- . . . /usr/include/include/pshpack2.h:22:4: #error "Alignment nesting > 3 is not supported" In file included from /usr/include/include/afxcmn.h:38, from StdAfx.h:20, from vctest.cpp:4: /usr/include/include/pshpack4.h:22:4: #error "Alignment nesting > 3 is not supported" In file included from /usr/include/include/poppack.h:31, from /usr/include/include/pshpack2.h:38, from /usr/include/include/poppack.h:31, from /usr/include/include/afxcmn.h:1132, from StdAfx.h:20, from vctest.cpp:4: /usr/include/include/pshpack2.h:22:4: #error "Alignment nesting > 3 is not supported" In file included from /usr/include/include/pshpack2.h:47, from /usr/include/include/poppack.h:31, from /usr/include/include/afxcmn.h:1132, from StdAfx.h:20, from vctest.cpp:4: /usr/include/include/pshpack2.h:22:4: #error "Alignment nesting > 3 is not supported" make: *** [vctest.o] Error 1 ---------------- I think the problem might be with -lmfc. Please kindly help me to come out of these errors. ______________________________________ Scanned and protected by Email scanner

Jan. 29, 2004

Re: Missing RedHat fc1 src rpm

by Vincent Béron

Le mer 28/01/2004 à 14:50, Mike Hearn a écrit : > On Wed, 28 Jan 2004 10:55:33 -0800, Bill Medland wrote: > > The sourceforge site seems to be missing the fc1 src rpm for the Jan 2004 > > build. > > My fault, I rolled the FC1 RPMs this time as Vincents machine is b0rked. I > just forgot to upload the SRPM along with the binaries to SourceForge > incoming. I'm doing that now so when a SF admin releases the files it > should be available. Thanks Mike. It's released now. Vincent

Jan. 29, 2004

Re: File change notifications

by Duane Clark

Hans Leidekker wrote: > + > +/* TODO: - security attribute changes > + * - compound filter and multiple notifications > + * - subtree notifications > + * - non-documented flags FILE_NOTIFY_CHANGE_LAST_ACCESS and > + * FILE_NOTIFY_CHANGE_CREATION > + For some reason, a comment end is missing there. But otherwise, it seems to work fine with the one important app I use file notification on.

Jan. 29, 2004

version.dll implementation

by Abdul-Haseeb Ahmad

seems the problem with nhl2004 is wine's current implementation of version.dll... seems as though GetFileVersionInfoA is critical to BrowserEngine_PC_z.dll... does anyone here know version.dll well and would care to share some insight? Quoting Abdul-Haseeb Ahmad <abdul.ahmad(a)utoronto.ca>: > ive tinkered around some more, and i copied over winxp's kernel32.dll, and > i > created a blank lz32.dll (was also giving an error), and it wasn't loading > browserengine_pc_z.dll due to the implementation of version.dll: > > err:module:import_dll Loading module (file) lz32.dll (which is needed by > L"C:\\WINDOWS\\SYSTEM\\version.dll") failed (error c0000020). > err:module:import_dll No implementation for lz32.dll.LZClose imported from > L"C:\\WINDOWS\\SYSTEM\\version.dll", setting to 0xdeadbeef > err:module:import_dll No implementation for lz32.dll.LZCopy imported from > L"C:\\WINDOWS\\SYSTEM\\version.dll", setting to 0xdeadbeef > err:module:import_dll No implementation for lz32.dll.LZOpenFileA imported > from > L"C:\\WINDOWS\\SYSTEM\\version.dll", setting to 0xdeadbeef > err:module:import_dll No implementation for lz32.dll.LZRead imported from > L"C:\\WINDOWS\\SYSTEM\\version.dll", setting to 0xdeadbeef > err:module:import_dll No implementation for lz32.dll.LZSeek imported from > L"C:\\WINDOWS\\SYSTEM\\version.dll", setting to 0xdeadbeef > err:module:import_dll Module (file) VERSION.dll (which is needed by > L"Z:\\mnt\\d\\nhlwine\\BrowserEngine_pc_z.dll") not found > err:module:import_dll No implementation for VERSION.dll.VerQueryValueA > imported > from L"Z:\\mnt\\d\\nhlwine\\BrowserEngine_pc_z.dll", setting to 0xdeadbeef > err:module:import_dll No implementation for > VERSION.dll.GetFileVersionInfoSizeA > imported from L"Z:\\mnt\\d\\nhlwine\\BrowserEngine_pc_z.dll", setting to > 0xdeadbeef > err:module:import_dll No implementation for VERSION.dll.GetFileVersionInfoA > imported from L"Z:\\mnt\\d\\nhlwine\\BrowserEngine_pc_z.dll", setting to > 0xdeadbeef > No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\CABINET.DLL' > (0x5c00000) > No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MPR.DLL' (0xfa0000) > No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WININET.DLL' > (0x4ab0000) > No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\URLMON.DLL' > (0x5cd0000) > err:ole:CoGetClassObject couldn't load InprocServer32 dll > Z:\mnt\d\nhlwine\BrowserEngine_pc_z.dll > > > so i copied over version.dll as well, and it started to give an invalid > address > error as well, i tried creating a blank version.dll as well, but it still > wouldnt load BrowserEngine_pc_z.dll > > > > Quoting Abdul-Haseeb Ahmad <abdul.ahmad(a)utoronto.ca>: > > > Okay guys, I'm a first time poster here, so sorry if I goofed up > somewhere. > > > > The full bug report is here, includes full output: > > http://bugs.winehq.org/show_bug.cgi?id=1970 > > > > okay heres my testing report of NHL 2004.. I decided to go the full > length > > to > > see if we can get it working because IE6 does work in wine, and Madden > 2004, > > an > > EAGL-engined game (NHL 2004 also uses the same engine, although probably > a > > slightly older revision than Madden, both dx8 though), works with little > > graphical glitches. > > > > running wine20031212 compiled from source on fedora core release 1 > > installed IE6 using mike hearn's install script > > installed NHL 2004: > > - ran "wine Autorun.exe &" in /mnt/cdrom > > - changed directory out of cdrom to allow switching of CDs > > - said no to new version of DCOM installation > > - said yes to Flash Player installation (no errors, unlike winex) > > - advanced install > > - typed in directory i wanted to install it into (browse is buggy, > crashes > > when > > you click OK) > > - (installed it on a fat32 partition) > > - chose register later > > - said no to installing EA Online components > > - progress meter frozen at 0.00% but files copied > > - error copying Support\en-us_eahelp.GID > > - unmounted cd, created /mnt/cdrom/Support > > - created missing file with "touch en-us_eahelp.GID" > > - retried, error copying with Support\go_ez.exe > > - deleted /mnt/cdrom/Support/en-us_eahelp.GID > > - rmdir'd /mnt/cdrom/Support > > - remounted cd, clicked retry, cd continued to copy files > > - install asked for cd2, switched to cd2, clicked ok, files continued to > > copy, > > indicator still at 0.00% though > > - install goes to Please wait window for a 5 or 6 minutes > > - screen pops up saying a debugger has been detected (install completed) > > - copied v1.0 nocd crack into nhl 2004 directory > > > > afterwards is the output i got running the wine20031212 debugger > > > > > > okay, so I'm pretty sure that BROWSERENGINE_PC_Z.DLL is what NHL 2004 > uses > > to > > communicate with IE6 (NHL 2004 uses HTML/JS files for its menu interface) > > > > I when i load intro.html (the first page that NHL 2004 runs) into IE6 it > > doesnt > > show anything when in windows when opening it in IE6 it shows the intro > > video > > (an mpg file)... however title.html does appear correctly (its a very > basic > > html > > file) so i backed-up my intro.html and copied the title.html file over > > intro.html, yet the errors i got were still the same, so the error seems > to > > unrelated to the content of the HTML file that is being loaded, if it > even > > gets > > to that stage. The game does create the My Documents/NHL 2004 directory > > correctly. I copied over the My Documents/NHL 2004 directory over from my > > windows installation and I still got the same error. > > > > The game does go into a full screen 800x600 mode, but the game just sits > > there > > with a frozen image of the desktop (in winex i get a black screen with > the > > white > > windows mouse pointer as it should be, but thats a different story > because > > winex > > doesnt even run IE), so i had to alt-tab to see the proper terminal > window > > again... the debugger keeps on outputting the same thing over at the end > when > > i > > type cont, and thats where both outputs end (actually the second output > > ends > > with wine not finding the debugged because i didnt have it setup > properly) > > > > anyone know what the BROWSERENGINE_PC_Z.DLL is trying to call at the end > when > > i > > get this as the trace (im not sure exactly how to read the order of what > > calling > > what, browserengine_pc_z calling kernel21, or the other way around): > > > > =>0 0x1000997a (BROWSERENGINE_PC_Z.DLL.DllGetClassObject+0x42fa in > > BROWSERENGINE_PC_Z.DLL) (ebp=003afc34) > > 1 0xe8530845 (KERNEL32.DLL.VerSetConditionMask+0xd803581b) > (ebp=8be58955) > > *** Invalid address 0x8be58955 > > (KERNEL32.DLL.VerSetConditionMask+0x7b95d92b) > > > > also, I made sure that IE still functions after the installation of NHL > > 2004. > > However IE6 doesn't seem to be able to play SWF files, even though that > > shouldnt > > be a major factor, as I know people who have had the game in windows > without > > the > > flash parts showing > > > > any help would be appreciated. there is an NHL 2004 demo and im sure it > > would > > probably behave the same, although you might have to install it through a > > windows installation if its giving problems installing the demo in wine. > > > > also if there is a better forum to post this information so it can be > used, > > please tell me. > > > > > > > >

Jan. 28, 2004

Re: desktop mode again

by Alex Pasadyn

Robert Shearman wrote: > I suggest you put the system metrics stuff in a separate patch. It is a lot more tested and more likely to get in than the other code, which is quite a big change. I can do that, if it would get applied. :) I sent an earlier version of the sysmetrics patch by itself a long time ago, and it was not applied because it could give incorrect results in desktop mode. This version is cleaner that that one, and I think that by itself it would at least give correct results for an application running in the one desktop that changed its size. So, Alexandre? Is that worth sending? > I guess we need test cases for those then. > The way I see it the only way around the problem of inter-process graphics operations is for us to have our own DIB engine and move functions calling WIN_FindWndPtr into the server. X doesn't allow inter-process operations right? Actually, I think X doesn't care. It has no problem with me having one process create the desktop window and another process creating a "normal" window inside it. Or did you mean something else? >>@@ -128,7 +129,14 @@ >> */ >> BOOL WINAPI PaintDesktop(HDC hdc) >> { >>- HWND hwnd = GetDesktopWindow(); >>+ HWND hwnd; >>+ SERVER_START_REQ( set_desktop_window ) >>+ { >>+ req->handle = 0; >>+ wine_server_call( req ); >>+ hwnd = reply->cur_handle; >>+ } >>+ SERVER_END_REQ; >> >> /* check for an owning thread; otherwise don't paint anything (non-desktop mode) */ >> if (GetWindowThreadProcessId( hwnd, NULL )) > > > Is there some reason for replacing GetDesktopWindow with this server call? Yes. The problem is that the winedesktop app thinks the "root" X window is the desktop, while all other apps think the window winedesktop created is the desktop. For convenience, winedesktop is just calling PaintDesktop when appropriate. I did not want to just copy the body of that function into winedesktop because it depends on other variables in the file where it is located. I guess the alternative would be to have the set wallpaper, set pattern, and paintdesktop functions simply send a message to the winedesktop process (if it's running), which would then contain the implementations. If that sounds more reasonable I can certainly change it to that way. >>+/*********************************************************************** >>+ * BecomeDesktop >>+ * >>+ * Tell the server to make our window the desktop. >>+ */ >>+static BOOL BecomeDesktop() >>+{ >>+ BOOL res = TRUE; >>+ SERVER_START_REQ( set_desktop_window ) > > > This is bad. There shouldn't be a direct server call in a normal wine program. We should try and find the right Windows API to do this, or create our own export from user32. Only user32, gdi32, ntdll and x11drv should need to use server calls (and kernel32 out of convenience). I guess I have no opinion about whether it would be worse to create a new export or just call the server. I was not happy about doing either, but I am not aware of anything in the "real" API that would do this. This application is not really "normal" anyway. I see it more as an extension of x11drv. > Why do you need two windows procedures? If you're sure you do need both of them, a comment in the code explaining why would be good. It's not at all obvious to the casual observer (i.e. me) otherwise. That I can add. The basic thing is that the "main" window created by winedesktop is just a normal ordinary window, and it can be minimized, etc. The child window came in because an app should be able to ask for the size of the desktop window and always get the right answer. I thought it was better to create a child window than to have to put code in the server to intercept calls to get the size of the desktop and fudge the results if it was minimized. > It appears you don't launch winedesktop anywhere and you don't remove any options from the config file. It will be a bit confusing for people who do use the wine desktop when it doesn't do anything after applying your patch (until they launch winedesktop). Do you plan to launch winedesktop at startup (possibly just after wineserver is launched) if the desktop setting is enabled? This was described when I originally posted a version of this a long time ago. The general idea is that if no other Wine apps are running, you can start winedesktop. While it's running, all Wine apps that get started get trapped inside the desktop. I would like to find a way to have multiple desktops or desktop coexisting with non-desktop, but that would be a ton of additional bookkeeping in the server. Alex

Jan. 28, 2004

Re: Posix Subsystem for ReactOS - Project 2010

by Shachar Shemesh

Steven Edwards wrote: >My plan is to work with the CoLinux team to integrate CoLinux in to >Windows and ReactOS as a POSIX subsystem. They are very interested in >working with us on this project and have linked to reactos.com on the >website. > > My entire experience with CoLinux has to do with Dan Aloni grabbing me at a random hall a few weeks ago and telling me about it (actually - the first he did it was about half a year ago, but he really got my attention, making me late for a meeting, this time around). While it's certainly an exiting project, I understood that it was NOT based on the Windows subsystem mechanism, but rather hacking your way into Windows NT's ring 0 using a device driver. While I'm a great fan of "if it works", wouldn't it be nicer, long run, to have a proper subsystem of it? Also, what are you planning on doing with graphic applications? CoLinux works by running a X server on the windows machine. That's probably not the best solution there is. How is the ReactOS windowing back-end implemented? Shachar

Jan. 28, 2004

Re: desktop mode again

by Robert Shearman

I apologise in advance if this message is poorly formatted. Blame webmail for that. Alex Pasadyn wrote: > ChangeLog: > - Make a separate process for the Wine desktop window > - In desktop mode, all applications share one desktop window > - Ensure system metrics are accurate for all processes after resolution > changes I suggest you put the system metrics stuff in a separate patch. It is a lot more tested and more likely to get in than the other code, which is quite a big change. [snip] > While several applications work fine, there are > some issues I have not been able to resolve. The problems have to do > with trying to call WIN_FindWndPtr across processes, especially from the > windows/painting.c file. As you rightly say, we need to move a lot of the window code into wineserver. ReactOS probably has a head start on us in this area, although we won't be able to borrow anything more than ideas because of the license. [snip] > I am hoping someone with more knowledge of the painting and region > code could spot some obvious way to get around the issue. Otherwise it > will be tough. I had tried replacing some of the WND* uses with server > calls to get rectangles and style flags, but that does not handle > everything that's being read out of those structures. Unless there's > some shortcut I don't see how to do it without moving more of that data > into the server. The other problem related to this is that some > functions are supposed to fail if the window is in another process, > while others would work better if they got the data from the server, and > it's not always obvious which way a particular function should work. I guess we need test cases for those then. The way I see it the only way around the problem of inter-process graphics operations is for us to have our own DIB engine and move functions calling WIN_FindWndPtr into the server. X doesn't allow inter-process operations right? > @@ -128,7 +129,14 @@ > */ > BOOL WINAPI PaintDesktop(HDC hdc) > { > - HWND hwnd = GetDesktopWindow(); > + HWND hwnd; > + SERVER_START_REQ( set_desktop_window ) > + { > + req->handle = 0; > + wine_server_call( req ); > + hwnd = reply->cur_handle; > + } > + SERVER_END_REQ; > > /* check for an owning thread; otherwise don't paint anything (non-desktop mode) */ > if (GetWindowThreadProcessId( hwnd, NULL )) Is there some reason for replacing GetDesktopWindow with this server call? [snip] > +/*********************************************************************** > + * BecomeDesktop > + * > + * Tell the server to make our window the desktop. > + */ > +static BOOL BecomeDesktop() > +{ > + BOOL res = TRUE; > + SERVER_START_REQ( set_desktop_window ) This is bad. There shouldn't be a direct server call in a normal wine program. We should try and find the right Windows API to do this, or create our own export from user32. Only user32, gdi32, ntdll and x11drv should need to use server calls (and kernel32 out of convenience). [snip] > +/*********************************************************************** > + * WrapperWndProc > + * > + * Window procedure > + */ > +static LRESULT WINAPI WrapperWndProc( HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam ) [snip] > +/*********************************************************************** > + * DesktopWndProc > + * > + * Window procedure > + */ > +static LRESULT WINAPI DesktopWndProc( HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam ) Why do you need two windows procedures? If you're sure you do need both of them, a comment in the code explaining why would be good. It's not at all obvious to the casual observer (i.e. me) otherwise. It appears you don't launch winedesktop anywhere and you don't remove any options from the config file. It will be a bit confusing for people who do use the wine desktop when it doesn't do anything after applying your patch (until they launch winedesktop). Do you plan to launch winedesktop at startup (possibly just after wineserver is launched) if the desktop setting is enabled? Rob

Jan. 28, 2004

Re: UXTHEME

by Kevin Koltzau

Win98 doesn't have themes, so you've got nothing to worry about as far as registry settings go. Only WinXP and Win2003 (and anything newer then those) have theming support On Wednesday 28 January 2004 02:14 pm, MediaHost \(TM\) wrote: > OK, good to know! Anyway, I made a import of a registry file to the > registry which helped me get many apps running (From my daughters Win98) > and I'll be glad to remove the theme.....Anyone know what to remove? I > never played with themes and certainly not on a Win98 :-) > > I see this also bothering Winamp 5....would maybe run too.

Jan. 28, 2004