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

Re: Named pipes

by Peter Riocreux

Mike McCormack <mike(a)codeweavers.com> writes: > Peter Riocreux wrote: > > > fixme:ole:CoRegisterMessageFilter stub > > warn:heap:HEAP_ValidateInUseArena Heap 40220000: invalid in-use arena magic for 402576a0 > > warn:ole:create_marshalled_proxy Could not open named pipe to broker \\.\pipe\{46A9F31C-E868-11D4-8BC9-000102A831DC}, le is 2 > > [last message repeated indefinitely] > This is a problem with OLE32, not with named pipes. The interprocess > marshalling code in Wine's OLE32 implementation is not yet complete... Thanks for the diagnosis. Is it something that someone is working on, but just not finished, or is it something that nobody is really attacking at the moment? The status system on the website suggests it is 60% complete, and it was last mentioned in WWN #117, but that isn't necessarily a guide to activity on it. Is it something that someone not steeped in the magic of Wine/Windows might be able to hack on? If it is practical for me to do so in my limited spare time, I would happily write code in exchange for guidance... Peter

Jan. 28, 2004

Re: Named pipes

by Uwe Bonnes

>>>>> "Peter" == Peter Riocreux <par+wine_devel(a)silistix.com> writes: Peter> "Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> writes: >> > warn:heap:HEAP_ValidateInUseArena Heap 40220000: invalid in-use > >> arena magic for 402576a0 >> >> Worrying, but your program hasn't crashed so shouldn't be a problem. Peter> Well the thing that I *think* should be on the other end of the Peter> pipe crashes with a similar message: Peter> warn:heap:HEAP_ValidateInUseArena Heap 40220000: invalid in-use Peter> arena magic for 40257990 Run with --debugmsg +heap , eventaully with --debugmsg +relay,+heap. That way, wine checks the heap on every heap access and stops and prints a debug when the heap is strange. However the logs tend to get long and the execution speed to crawl... Hope this helps -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Jan. 28, 2004

Re: Named pipes

by Peter Riocreux

"Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> writes: > > warn:heap:HEAP_ValidateInUseArena Heap 40220000: invalid in-use > > arena magic for 402576a0 > > Worrying, but your program hasn't crashed so shouldn't be a problem. Well the thing that I *think* should be on the other end of the pipe crashes with a similar message: warn:heap:HEAP_ValidateInUseArena Heap 40220000: invalid in-use arena magic for 40257990 The only other occurrance of that address (40257990) for the putative server process is: trace:heap:RtlAllocateHeap (0x40220000,00000002,00000108): returning 40257990 As I am a novice at this wine debugging malarchy, I don't know what an arena is, much less its magic, so I have no idea how I might determine if the application is currupting it or there is a wine bug. (acknowledging of course that wine has *no* bugs ... :-P) > > warn:ole:create_marshalled_proxy Could not open named pipe to > > broker \\.\pipe\{46A9F31C-E868-11D4-8BC9-000102A831DC}, le is 2 > > [last message repeated indefinitely] > > Probably the real cause. That pipe path isn't a standard Windows one. Is > there some server software you should run? I think I have found a server binary (see above), but it crashes so I am not sure. Can I use nm or something similar to look for calls to whatever functions are likely to create the pipe, so as to at least make sure I am dealing with the correct binary. (we have no instructions yet...) > > It also looks for, and doesn't find, ADVAPI32.dll. > > You have run with warn+all right? Yes. > That means it is a bit verbose when loading DLLs. If wine really > can't find a DLL it will let you know in an err: message. I get no err messages. Is it reasonably safe therefore to assume that it would *like* this dll, but doesn't *need* it.

Jan. 28, 2004

Re: WineHQ: Isn't status update news?

by Brian Vincent (C)

> How about a news item about the status being updated? > Tom just finished a big status update, and people that > don't follow wine-{cvs,devel,patches}(a)winehq.org have > no way of knowing. I was under the impression it wasn't completed yet because the Core page still needed to be done. --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

Jan. 28, 2004

Re: Mouse up vs Mouse click

by Fabian Cenedese

>>The misbehaving app uses a ownerdrawn, CListCtrl-derived list. When >>I click on a cell not in the first column the cell gets selected. But on >>wine I can see that the selection flashes shortly and disappears right >>again (Surprisingly it works when I click in the first column. As my >>application uses the same code for all columns it must be something >>else.). After putting some debug messages in my code I found that >>on Windows after the left-button-down event a left-button-click event >>is generated, no matter how long I hold the button before releasing. >>On wine there is no click event but a mouse up event. And the cell >>flashes even when I hold the button, so it's not the releasing itself >>that clears the selection. >> >>The control is a bit quirky with moving focus around and handling events >>specially. But still it works on Windows :) Now I'm a bit lost how I can >>debug this. +mouse didn't show anything usefull. I guess the >>generating and sending of the events is done in the wineserver. >> Could somebody explain me (or direct me to info) how this should work >> in general? I mean even on Windows, when is something a click and >> when a down/up or down/click? I know that a too slow double-click will >> be two separate clicks, but I'm uncertain about the down/up events. > >This is what I know of it: the translations happen in the >PeekMessage/GetMessage calls. If you follow the logic in >windows/message.c, you see that the raw hardware messages are processed >several times, and that a simple hardware message like mouse button up >or down can lead to several others. Not only clicks/double clicks but >also WM_SETCURSOR, WM_PARENTNORIFY, WM_ACTIVATE* and other (especially >hooks) message that may come with a mouse click are generated there. I tried again to find this problem. I couldn't find any difference in how the mouse messages are generated/handled between the two cases (clicking on first column/not first column). I now start to think that it's more a focus problem. If the focus is immediately shifted away after getting it it might look like the flashing cell I have now. To find out more about the focus I made some traces with +win. This is from clicking on the first column (works ok). In fact I have already clicked before on a different line in the first column so the listbox surely already has the focus: trace:event:EVENT_ProcessEvent Got event ButtonPress for hwnd/window 0x2002c/2200016, GetFocus()=0x2002c trace:cursor:send_mouse_event (8002,485,403) trace:event:EVENT_ProcessEvent returns. trace:win:WINPOS_WindowFromPoint scope 0x20029 485,403 trace:win:GetWindowRect hwnd 0x2002c (430,367)-(730,517) trace:win:WINPOS_WindowFromPoint found child 0x2002c trace:win:WIN_SetWindowLong 0x20029 0 0 3 trace:win:WIN_SetWindowLong 0x20029 0 0 3 trace:win:RedrawWindow 0x2002c ((nil)) rect 0,17-200,31 (nil) flags=0005 trace:win:dump_rdw_flags flags: RDW_INVALIDATE RDW_ERASE trace:win:RDW_UpdateRgns hwnd 0x2002c [0x145a] -> hrgn [(nil)], flags [0005] trace:win:RDW_Paint hwnd 0x2002c [0x145a] -> hrgn [(nil)], flags [0005] trace:win:RedrawWindow 0x2002c (0x145a) rect 0,17-200,31 (nil) flags=0005 trace:win:dump_rdw_flags flags: RDW_INVALIDATE RDW_ERASE trace:win:RDW_UpdateRgns hwnd 0x2002c [0x145a] -> hrgn [0x145e], flags [0005] trace:win:RDW_Paint hwnd 0x2002c [0x145a] -> hrgn [0x145e], flags [0005] trace:win:RedrawWindow 0x2002c (0x145a) rect 0,31-200,45 (nil) flags=0005 trace:win:dump_rdw_flags flags: RDW_INVALIDATE RDW_ERASE trace:win:RDW_UpdateRgns hwnd 0x2002c [0x145a] -> hrgn [0x145e], flags [0005] trace:win:RDW_Paint hwnd 0x2002c [0x145a] -> hrgn [0x145e], flags [0005] trace:win:RedrawWindow 0x2002c (0x145a) rect 0,31-200,45 (nil) flags=0005 trace:win:dump_rdw_flags flags: RDW_INVALIDATE RDW_ERASE trace:win:RDW_UpdateRgns hwnd 0x2002c [0x145a] -> hrgn [0x145e], flags [0005] trace:win:RDW_Paint hwnd 0x2002c [0x145a] -> hrgn [0x145e], flags [0005] trace:win:RedrawWindow 0x2002c (0x145a) NULL 0,0-0,0 (nil) flags=0180 trace:win:dump_rdw_flags flags: RDW_ALLCHILDREN RDW_UPDATENOW trace:win:RDW_UpdateRgns hwnd 0x2002c [0x145a] -> hrgn [(nil)], flags [0180] trace:win:RDW_UpdateRgns hwnd 0x2002d [(nil)] -> hrgn [(nil)], flags [0180] trace:win:RDW_Paint hwnd 0x2002c [0x145a] -> hrgn [(nil)], flags [0180] trace:win:begin_ncpaint hwnd 0x2002c [0x145a] ncf 0 trace:win:BeginPaint hdc = 0x74 box = (0,17 - 200,45) trace:win:BeginPaint hdc = 0x74 box = (0,17 - 200,45), fErase = 0 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event ButtonRelease for hwnd/window 0x2002c/2200016, GetFocus()=0x2002c trace:cursor:send_mouse_event (8004,485,403) trace:event:EVENT_ProcessEvent returns. trace:win:WIN_SetWindowLong 0x20029 0 0 3 trace:event:EVENT_ProcessEvent called. This is from clicking on the second column (doesn't work). Note the additional BeginPaint in the middle and the different paint flags: trace:event:EVENT_ProcessEvent Got event ButtonPress for hwnd/window 0x2002c/2200016, GetFocus()=0x2002c trace:cursor:send_mouse_event (8002,520,406) trace:event:EVENT_ProcessEvent returns. trace:win:WINPOS_WindowFromPoint scope 0x20029 520,406 trace:win:GetWindowRect hwnd 0x2002c (430,367)-(730,517) trace:win:WINPOS_WindowFromPoint found child 0x2002c trace:win:WIN_SetWindowLong 0x20029 0 0 3 trace:win:WIN_SetWindowLong 0x20029 0 0 3 trace:win:RedrawWindow 0x2002c ((nil)) rect 0,31-200,45 (nil) flags=0005 trace:win:dump_rdw_flags flags: RDW_INVALIDATE RDW_ERASE trace:win:RDW_UpdateRgns hwnd 0x2002c [0x145a] -> hrgn [(nil)], flags [0005] trace:win:RDW_Paint hwnd 0x2002c [0x145a] -> hrgn [(nil)], flags [0005] trace:win:RedrawWindow 0x2002c (0x145a) NULL 0,0-0,0 (nil) flags=0180 trace:win:dump_rdw_flags flags: RDW_ALLCHILDREN RDW_UPDATENOW trace:win:RDW_UpdateRgns hwnd 0x2002c [0x145a] -> hrgn [(nil)], flags [0180] trace:win:RDW_UpdateRgns hwnd 0x2002d [(nil)] -> hrgn [(nil)], flags [0180] trace:win:RDW_Paint hwnd 0x2002c [0x145a] -> hrgn [(nil)], flags [0180] trace:win:begin_ncpaint hwnd 0x2002c [0x145a] ncf 0 trace:win:BeginPaint hdc = 0x74 box = (0,31 - 200,45) trace:win:BeginPaint hdc = 0x74 box = (0,31 - 200,45), fErase = 0 trace:win:RedrawWindow 0x2002c ((nil)) rect 0,31-200,45 (nil) flags=0005 trace:win:dump_rdw_flags flags: RDW_INVALIDATE RDW_ERASE trace:win:RDW_UpdateRgns hwnd 0x2002c [0x145a] -> hrgn [(nil)], flags [0005] trace:win:RDW_Paint hwnd 0x2002c [0x145a] -> hrgn [(nil)], flags [0005] trace:win:RedrawWindow 0x2002c (0x145a) NULL 0,0-0,0 (nil) flags=0050 trace:win:dump_rdw_flags flags: RDW_NOINTERNALPAINT RDW_NOCHILDREN trace:win:RDW_UpdateRgns hwnd 0x2002c [0x145a] -> hrgn [(nil)], flags [0050] trace:win:RDW_Paint hwnd 0x2002c [0x145a] -> hrgn [(nil)], flags [0050] trace:win:RedrawWindow 0x2002c (0x145a) NULL 0,0-0,0 (nil) flags=0050 trace:win:dump_rdw_flags flags: RDW_NOINTERNALPAINT RDW_NOCHILDREN trace:win:RDW_UpdateRgns hwnd 0x2002c [0x145a] -> hrgn [(nil)], flags [0050] trace:win:RDW_Paint hwnd 0x2002c [0x145a] -> hrgn [(nil)], flags [0050] trace:win:begin_ncpaint hwnd 0x2002c [0x145a] ncf 0 trace:win:BeginPaint hdc = 0x74 box = (0,31 - 200,45) trace:win:BeginPaint hdc = 0x74 box = (0,31 - 200,45), fErase = 0 trace:win:WIN_SetWindowLong 0x20029 0 0 3 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event ButtonRelease for hwnd/window 0x2002c/2200016, GetFocus()=0x2002c trace:cursor:send_mouse_event (8004,520,406) trace:event:EVENT_ProcessEvent returns. trace:win:WINPOS_WindowFromPoint scope 0x20029 520,406 trace:win:GetWindowRect hwnd 0x2002c (430,367)-(730,517) trace:win:WINPOS_WindowFromPoint found child 0x2002c trace:win:WIN_SetWindowLong 0x20029 0 0 3 trace:win:WIN_SetWindowLong 0x20029 0 0 3 trace:event:EVENT_ProcessEvent called. What happens here in between? Why does this get two paint events whereas in the first column it does not? Are there some other debug channels that could help me? I already use mouse, event, listbox, listctrl, cursor, win plus my own messages in the wine code. Thanks bye Fabi

Jan. 28, 2004

Re: Fix .. in path names

by Dimitrie O. Paun

On Wed, 28 Jan 2004, Mike McCormack wrote: > This patch fixes the problem with non-existant directories and .. in > pathnames. (and it makes my test case work, Dimi!) > + /* don't mess with unix path names */ > + if( strchrW(name,'/') ) > + return DOSFS_GetFullNameNoDots( name, check_last, full ); I don't think this is a good test for Unix path names. AFAAIK, DOS supports '/' as well as path separator. Maybe we should export a wine_is_unix_path() function... -- Dimi.

Jan. 28, 2004

RE: Named pipes

by Robert Shearman

> > > The management software (binary called pm5.exe) installed fairly > easily and gets a long way in on execution but then stops making > progress. It consumes pretty much all the CPU and when run with debug > messages printed I get the following: > > fixme:ole:CoRegisterMessageFilter stub Should be harmless. > warn:heap:HEAP_ValidateInUseArena Heap 40220000: invalid in-use > arena magic for 402576a0 Worrying, but your program hasn't crashed so shouldn't be a problem. > warn:ole:create_marshalled_proxy Could not open named pipe to > broker \\.\pipe\{46A9F31C-E868-11D4-8BC9-000102A831DC}, le is 2 > [last message repeated indefinitely] Probably the real cause. That pipe path isn't a standard Windows one. Is there some server software you should run? > There are two earlier instances of the first message, so I don't think > that is the fundamental problem, but that is the first and only HEAP > message, and the last message gets repeated endlessly. (full logs > available on request). > > It also looks for, and doesn't find, ADVAPI32.dll. You have run with warn+all right? That means it is a bit verbose when loading DLLs. If wine really can't find a DLL it will let you know in an err: message. > I am not a Windows person at all, so have no idea if the above dll is > one that I should expect to find somewhere, or likely to be from the > app itself. As for the pipe thing, I couldn't tell whether it couldn't > connect because it couldn't make a pipe, or because it could but there > was nothing at the end of it. (I am assuming the 'broker' is at the > other end of the pipe.) Yes, try looking for something that needs to be at the other end of the pipe (most likely another executable). Rob

Jan. 28, 2004

WineHQ: Isn't status update news?

by Dimitrie O. Paun

Guys, How about a news item about the status being updated? Tom just finished a big status update, and people that don't follow wine-{cvs,devel,patches}(a)winehq.org have no way of knowing. In general, I think any big site update should make it as news items. -- Dimi.

Jan. 28, 2004

Named pipes

by Peter Riocreux

[reposted because I posted not from the subscribed address - Doh! Sorry if you see it twice in the end] Using the RH9 RPM from the SF downloads area (wine-20040121-1rh9winehq.i686.rpm) This is my first serious attempt at getting a non-working app working, so if I am giving insufficient, or the wrong kind of, info, or am asking on the wrong list, or have not found the blindingly-obvious-to-everyone-but-me FAQ covering something then please point me at the right things. At my company, we have just purchased a spangly new Alcatel telephone exchange, and despite the exchange running Linux apparently (I am going to start work on obtaining the source next week ...), they have only a Windows client for managing this exchange. Thus Wine .... The management software (binary called pm5.exe) installed fairly easily and gets a long way in on execution but then stops making progress. It consumes pretty much all the CPU and when run with debug messages printed I get the following: fixme:ole:CoRegisterMessageFilter stub warn:heap:HEAP_ValidateInUseArena Heap 40220000: invalid in-use arena magic for 402576a0 warn:ole:create_marshalled_proxy Could not open named pipe to broker \\.\pipe\{46A9F31C-E868-11D4-8BC9-000102A831DC}, le is 2 [last message repeated indefinitely] There are two earlier instances of the first message, so I don't think that is the fundamental problem, but that is the first and only HEAP message, and the last message gets repeated endlessly. (full logs available on request). It also looks for, and doesn't find, ADVAPI32.dll. I am not a Windows person at all, so have no idea if the above dll is one that I should expect to find somewhere, or likely to be from the app itself. As for the pipe thing, I couldn't tell whether it couldn't connect because it couldn't make a pipe, or because it could but there was nothing at the end of it. (I am assuming the 'broker' is at the other end of the pipe.) Can anyone advance my state here? Cheers, Peter

Jan. 28, 2004

Re: NHL 2004 Testing Report

by Abdul-Haseeb Ahmad

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