- Wine-Devel - list.winehq.org

64bit Wine?
by J. Grant Dec. 2, 2003

Dec. 2, 2003

Hello I'm considering getting an Opteron. With this being a 64bit CPU I wondered if there would be any issues with using WINE to make use of win32 software on this 64bit CPU. Kind regards JG p.s. I'm not subscribed to this list from this email address, so please include my email address in any replies.

4 4

wine in the press
by Tom Dec. 2, 2003

Dec. 2, 2003

http://www.osnews.com/story.php?news_id=5262 ill add it to the press page in a couple days ill look around for other articles as well. Tom

2 1

Wineinstall, Regedit seg faults
by Fabian Cenedese Dec. 2, 2003

Dec. 2, 2003

Hi I just tried to install wine (from cvs 2003-12-02) on a fresh install of Knoppix (Debian). Configure/Compile went fine but I got an error with regedit as already reported here: http://bugs.winehq.org/show_bug.cgi?id=1664 In my case: Compiling regedit... make: nothing to do for "all" Preparing to install default wine registry entries... Installing default wine registry entries... tools/wineinstall: line 648: 10747 memory access error $REGEDIT $DEFREG >/dev/null Registry install failed. Is there something we can do to help? Anybody working on this? Thanks bye Fabi

1 1

Re: regedit: write support for strings
by Dimitrie O. Paun Dec. 2, 2003

Dec. 2, 2003

On December 1, 2003 04:51 pm, you wrote: > ChangeLog > Add support for editing strings. Please ignore this for now, I want to change a few things. I'll resubmit in a few minutes. -- Dimi.

1 0

Re: regedit: write support for strings
by Steven Edwards Dec. 2, 2003

Dec. 2, 2003

Hello Dimi, --- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > I figured I should so something a bit more "useful" (in light of > the 0.9 release), so here is the first attempt. It's not too much, > and not too good, but after looking at the code, it needs some > major cleanup before I can do any work on it. So the plan is: > -- get this in the tree, so I can cleanup my tree > -- cleanup the code (proper indentation, etc) > -- add more edit support to it. > > ChangeLog > Add support for editing strings. The ReactOS and WINE regedits are a little out of sync. Can you incorporate this in to your next patch? Thanks Steven Changelog: Filip Navara - Fixed some flags in calls to CreateWindowEx - Fixed Color of the splitter (should be COLOR_BTNFACE and not light gray brush) Steven Edwards - Change a few DbgPrint statements to WINE_TRACE __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

2 1

Re: pen: fix niggly problem with hatches
by Alexandre Julliard Dec. 2, 2003

Dec. 2, 2003

Andrew de Quincey <adq_dvb(a)lidskialf.net> writes: > + if (brush->lbHatch && (brush->lbStyle & ~(BS_SOLID|BS_HOLLOW))) > + FIXME("Hatches not implemented\n"); BS_SOLID etc. are not flags, you can't test them that way. -- Alexandre Julliard julliard(a)winehq.com

1 0

OpenOffice1.1.0 / wine-20031118 crash on startup
by Dan Kegel Dec. 2, 2003

Dec. 2, 2003

Pure, fresh install of wine-20031118 from sources on a dual processor Red Hat 9 machine. Installed winzip, used it to unpack OpenOffice1.1.0. Installed OpenOffice1.1.0. Install went fine. Found no 'soffice.exe' of any sort, so ran Winefile and double-clicked on the "Open Text Document.lnk" in c:\windows\OpenOffice1.1.0 directory. Boom! Wine puts me into the debugger: Unhandled exception: page fault on read access to 0x02010001 in 32-bit code (0x42079c30). In 32-bit mode. 0x42079c30 (NTDLL.DLL.strcpy+0x20): movzbl 0x0(%edx),%eax Wine-dbg>bt Backtrace: =>0 0x42079c30 (NTDLL.DLL.strcpy+0x20) (ebp=4072ed8c) 1 0x40778fd4 (SHELL32.DLL.FindExecutableW+0x7ec in SHELL32.DLL) (ebp=4072f840) 2 0x40779103 (SHELL32.DLL.ShellExecuteExA+0x1f in SHELL32.DLL) (ebp=4072f854) 3 0x40620515 (winefile.exe.EntryPoint+0x4515 in winefile.exe) (ebp=4072f9c4) 4 0x40620692 (winefile.exe.EntryPoint+0x4692 in winefile.exe) (ebp=4072f9f0) 5 0x40620a8c (winefile.exe.EntryPoint+0x4a8c in winefile.exe) (ebp=4072faa4) 6 0x408d0703 (USER32.DLL.EndDeferWindowPos+0x31b in USER32.DLL) (ebp=4072fac8) 7 0x408d0761 (USER32.DLL.EndDeferWindowPos+0x379 in USER32.DLL) (ebp=4072faf4) 8 0x408d4ff2 (USER32.DLL.EndDeferWindowPos+0x4c0a in USER32.DLL) (ebp=4072fb1c) 9 0x408d5645 (USER32.DLL.CallWindowProcW+0xf9 in USER32.DLL) (ebp=4072fb50) 10 0x408e50ab (USER32.DLL.IsCharAlphaW+0x2d57 in USER32.DLL) (ebp=4072fbac) 11 0x408e5e2d (USER32.DLL.SendMessageTimeoutW+0x135 in USER32.DLL) (ebp=4072fc10) 12 0x408e604d (USER32.DLL.SendMessageW+0x31 in USER32.DLL) (ebp=4072fc3c) 13 0x40895f32 (USER32.DLL.EditWndProc+0xaff6 in USER32.DLL) (ebp=4072fcd4) 14 0x40897359 (USER32.DLL.EditWndProc+0xc41d in USER32.DLL) (ebp=4072fcf8) 15 0x408d0703 (USER32.DLL.EndDeferWindowPos+0x31b in USER32.DLL) (ebp=4072fd1c) 16 0x408d0761 (USER32.DLL.EndDeferWindowPos+0x379 in USER32.DLL) (ebp=4072fd48) 17 0x408d5539 (USER32.DLL.CallWindowProcA+0xf9 in USER32.DLL) (ebp=4072fd7c) 18 0x40620d99 (winefile.exe.EntryPoint+0x4d99 in winefile.exe) (ebp=4072fda4) 19 0x408d0703 (USER32.DLL.EndDeferWindowPos+0x31b in USER32.DLL) (ebp=4072fdc8) 20 0x408d0761 (USER32.DLL.EndDeferWindowPos+0x379 in USER32.DLL) (ebp=4072fdf4) 21 0x408d5539 (USER32.DLL.CallWindowProcA+0xf9 in USER32.DLL) (ebp=4072fe28) 22 0x408b94a2 (USER32.DLL.DispatchMessageA+0x96 in USER32.DLL) (ebp=4072fe6c) 23 0x406214b9 (winefile.exe.EntryPoint+0x54b9 in winefile.exe) (ebp=4072fea4) 24 0x406214f1 (winefile.exe.EntryPoint+0x54f1 in winefile.exe) (ebp=4072febc) 25 0x4061c0a5 (winefile.exe.EntryPoint+0xa5 in winefile.exe) (ebp=4072ff2c) 26 0x4036b132 (KERNEL32.DLL.SetThreadExecutionState+0x16d6 in KERNEL32.DLL) (ebp=4072fff4) 27 0x4002df1d (_end+0x402c0f1) (ebp=00000000)

2 1

Problem with latest MDK package.
by Peter Nunn Dec. 2, 2003

Dec. 2, 2003

Hi folks, not sure if this belongs on this list or not, and its probably a stupidly simple question, but its got me stumped. I just installed the latest MDK package for wine (wine-20031118-mdk.i586) to update the one that shipped with MDK 9.2 (wine-20030813-1mdk.i586). Now, when I try and run wine I get wine: error while loading shared libraries: libwine.so.1: cannot open shared object file: No such file or directory libwine.so.1 is in /usr/lib/wine and I've run ldconfig after the package install, but still no joy. Any ideas what's going on here? The install also un-installed several other packages (not sure which ones though, good aren't I??) that I probably need to re-install too. It also removed the menu icons for wine and left XWine not functioning too (guess that's because wine doesn't work though). Thanks heaps. Peter Nunn. -- Think IT for your computing needs. InfoTeq Pty. Ltd.

1 0

Re: Installshield7 notes
by Daniel Kegel Dec. 2, 2003

Dec. 2, 2003

"Gregory M. Turner" <gmturner007(a)ameritech.net> wrote in reply to http://marc.theaimsgroup.com/?l=wine-devel&m=106746370617833&w=2 : > Could you recommend any particular installer that fails to me (preferably > something I can download for free)? I'd be happy to take a look at this, > although I can't make any promises as some code-paths (like stubless proxies) > are not likely to be fixed anytime soon. The installer for SourceStyler (a c++ beautifier available for free download from http://www.ochresoftware.com/download.html) It fails with the message "Installer terminated prematurely.", about the time Wine complains fixme:imagehlp:StackWalk (332, 0xffffffff, 0xfffffffe, 0x41b5bb44, 0x41b5c360, (nil), 0x42054e44, 0x42054e9c, (nil)): stub I would try the workarounds listed earlier in this thread, but don't have a native copy of Windows handy. - Dan

1 0

Re: shlwapi: optimise path functions
by Dimitrie O. Paun Dec. 1, 2003

Dec. 1, 2003

On November 29, 2003 06:27 pm, Andrew de Quincey wrote: > I've replaced the calls to CharNextA()/CharNextW() with array increments > and a local static function. This knocks 3.5 seconds off the file open > dialogue in IDA. Well, I'm not sure this is worth doing. First off, we're not fixing any app that makes use of CharNext{A,W}(). Second, why is your static method any faster than the real CharNextA()? Third, it's not correct to replace CharNextW() with an array increment. While it is true that currently our CharNextW() simply does the same thing, it should be fixed in the long run to properly deal with Unicode Surrogate Pairs: http://uk.geocities.com/BabelStone1357/Unicode/surrogates.html In other words, I don't think the patch is acceptable. What I'd suggest: -- figure out why the real CharNextA() is slow, and try to fix that -- figure out why it takes so long to call CharNextW() -- Dimi.

3 7