- Wine-Devel - list.winehq.org

Re: cabinet.dll broken?
by Tapio Kautto Nov. 29, 2002

Nov. 29, 2002

Could cabinet be set to: "cabinet" = "native,builtin" automatically by wineinstall as long as it does not work the way expected? Tapio On Thursday 28 November 2002 12:59, Patrik Stridvall wrote: > > I'm trying to install MS Office 2000 on wine-20021125. > > > > I get an error from Office installer: > > > > Internal error 2352. Please contact Product support. > > > > I found an advice to repair my cabinet.dll in Microsoft Support pages. > > > > The file is in ~/c/windows/system, and it's readable. Does > > anyone else have > > problem with this? > > Well. It might be that since very recently, Wine has builtin > stub implementation of cabinet.dll. > > Of course it shouldn't be used automatically if have a cabinet.dll, > since I guess most people (including you) have a: > > [DllOverrides] > ; default for all other dlls > "*" = "native, builtin, so" > > entry in their config file. > > You can force cabinet to native with > wine --dll cabinet=n > though.

1 0

Doc Build, Diablo II Regression Test, and TreeView Patch Test Updates
by Dustin Navea Nov. 29, 2002

Nov. 29, 2002

Vincent, Alexandre, and Dimi Grrr, Im really starting to not like Linux's PPPoE support... I have tried every version of pppd and pppoe that is available besides CVS (and thats because I cant get online in Linux to get it) in order to get my DSL workin in Linux and I am giving up until I can afford to get a DSL Router (hopefully next week). So until then, I will be unable to do any regression testing on Diablo II and will be unable to test out any of the most recent patches to verify that they fix problems with my setup... so until next Wednesday I will probably just lurk on the lists -Dustin

2 2

SIGSEGV in IDirectDrawImpl_EnumDisplayModes
by Matthew Bloch Nov. 29, 2002

Nov. 29, 2002

Apologies for needing some more hand-holding: from Alexander's advice I now have the game linking and beginning to execute. It now gets stuck while executing this piece of C++: --------------------------------------------------------------------------- void tDirectDrawScreen::destroy() { DDSURFACEDESC ddsd; memset(&ddsd,0,sizeof(DDSURFACEDESC)); ddsd.dwSize = sizeof(DDSURFACEDESC); ddsd.dwFlags = DDSD_CAPS; ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE; HRESULT hr = mp_directDraw->CreateSurface(&ddsd, &mp_primarySurface, NULL); // crashes here ... } --------------------------------------------------------------------------- This being the segfault that occurs: --------------------------------------------------------------------------- #0 0x40c92c4c in ?? () #1 0x40f56f5f in User_DirectDraw_EnumDisplayModes (iface=0x403acc00, dwFlags=1086925740, pDDSD=0x808c678, context=0x40c92be8, callback=0x40f55dfc <EnumDisplayModesCallbackThunk>) at ddraw/user.c:373 #2 0x40f55e81 in IDirectDrawImpl_EnumDisplayModes (This=0x40c92be8, dwFlags=1086925900, pDDSD=0x808c678, context=0x40c92a94, cb=0x40c92a94) at ddraw/thunks.c:348 #3 0x4080f9b2 in tDirectDrawScreen::setUpWindowedSurfaces (this=0x808c668) at Source/tDirectDrawScreen.cpp:852 #4 0x4080cf1f in tDirectDrawScreen::initialise (this=0x808c668, fullScreen=false, screenWidth=640, screenHeight=480) at Source/tDirectDrawScreen.cpp:88 #5 0x4080caac in tDirectDrawScreen::tDirectDrawScreen (this=0x808c668, fullScreen=false, screenWidth=640, screenHeight=480) at Source/tDirectDrawScreen.cpp:55 #6 0x4082d76f in InitApp (hInst=0x40620000, nCmdShow=1) at Source/Main.cpp:289 #7 0x4082d8fc in WinMain (hInst=0x40620000, hPrevInst=0x0, lpCmdLine=0x403708ad "", nCmdShow=1) at Source/Main.cpp:322 #8 0x4062509c in __wine_exe_main () from /home/mattbee/Work/Nemesis/LSNClient.exe #9 0x400b3799 in start_process () at ../../scheduler/process.c:564 #10 0x400b76c9 in call_on_thread_stack (func=0x400b3558) at ../../scheduler/sysdeps.c:112 --------------------------------------------------------------------------- Any ideas why this might be happening? -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026

9 22

Re: Last one for today :-)
by Vincent Béron Nov. 28, 2002

Nov. 28, 2002

Le jeu 28/11/2002 à 17:24, Lionel Ulmer a écrit : > re-reHi... > > This patch implements the 'GetRenderTarget' method for the IDirect3DDevice > COM object. It is independant from all previously submitted patches (but to > prevent 'fudging', it is better to commit after the GetDirect3D AddRef fix). > > With this series of patch, the Boids demo from the DX6 SDK is now running > (it's not working because we are lacking some D3D code, but at least it does > not crash :-) ). > > Changelog: > - implement GetRenderTarget A bit too much work on your part I bet, as you forgot to attach the patch ;-) Vincent

1 0

wine & preempt patch (fwd)
by Matthias Rieber Nov. 28, 2002

Nov. 28, 2002

Hi, is there are known issue with the preempt patch for the kernel? When I apply that patch, non-open-gl games doesn't run smooth, without the patch they run nearly smooth (especially StarCraft & BaldursGate). OpenGL games are alway fine. matthias

1 0

How to debug wineserver
by Rajesh Akkineni Nov. 28, 2002

Nov. 28, 2002

hi, is there any way we can debug the wineserver? thanks Rajesh __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

3 2

Modifying registers
by Fabian Cenedese Nov. 28, 2002

Nov. 28, 2002

Hi Is there already a possibility to view/set the actual program counter in winedbg? I couldn't find anything in the manual. And it's not possible to work with EIP. This would be useful e.g. to jump over some unwanted code or call a function a second time. Generally, is there a way to modify registers? Must be obvious but I'm blind. Thanks bye Fabi

3 3

Chronic crash on Photoshop
by Robert North Nov. 28, 2002

Nov. 28, 2002

Can someone look at the bug I raised about Photoshop crashing wine, (and potentially the whole of X11 and Linux) http://bugs.winehq.com/show_bug.cgi?id=1165 It's probably the most extreme bug I've seen on Linux ever. I wasn't sure if this was the appropriate place to post this request, so feel free to correct me. Cheers -Rob.

1 0

compiling wine under cygwin - status
by David Fraser Nov. 28, 2002

Nov. 28, 2002

Hi all This is a brief indicator on what parts of wine compile successfully under cygwin and what give errors. Almost all the source code compiles successfully, but lots of things have linking problems. Note that I haven't yet tested the resulting parts that did link successfully. The significant compilation problem is in server/context_i386.c: You must implement get/set_thread_context for your platform. Basically there's some code that does the threading stuff which is platform-specific. There are Linux and BSD and Sun variants, none of which work under cygwin ... Basically sys/ptrace.h is what's missing. This lets the process interrupt a child process and get/set its registers. Does anyone have any idea what the best way to write a replacement for cygwin would be? Maybe I need to ask the cygwin list. My plan is to go through each one that doesn't link, look at all the errors, and categorize them (many are the same problem spread accross various dlls), so that we can tackle the more widespread problems first... Any help with this appreciated :-) David dlls/ advapi32 has errors avicap32 has errors avifil32 has errors cabinet has errors comcat links comctl32 links commdlg has errors crtdll has errors crypt32 links d3d8 has errors dciman32 links ddraw has errors devenum links dinput links dinput8 links dplay links dplayx links dsound has errors gdi has errors glu32 links icmp links imagehlp links imm32 links kernel has errors lzexpand has errors mapi32 links mpr links msacm has errors msdmo links msimg32 links msisys has errors msnet32 links msvcrt has errors msvcrt20 has errors msvideo has errors netapi32 links ntdll has errors odbc32 links ole32 has errors oleaut32 has errors olecli has errors oledlg links olepro32 links olesvr has errors opengl32 has errors psapi has errors qcap links quartz links rasapi32 links richedit has errors rpcrt4 links serialui links setupapi has errors shdocvw links shell32 has errors shfolder links shlwapi links snmpapi links sti links tapi32 links ttydrv has errors twain has errors url links urlmon has errors user has errors version has errors win32s has errors winaspi has errors winedos has errors wineps has errors wininet has errors winmm has errors winnls has errors winsock has errors winspool has errors wintrust links wow32 links wsock32 links x11drv has errors library/ libwine.dll links successfully miscemu/ requires ntdll.dll ole/ libwine_uuid.a links successfully programs/ avitools/aviinfo.exe links avitools/aviplay.exe links clock/clock.exe links cmdlgtst/cmdlgtst.exe links control/control.exe links expand/expand.exe links osversioncheck/osversioncheck.exe links progman/progman.exe links regapi.exe/regapi.exe links regsvr32/regsvr32.exe links regtest/regtest.exe links uninstaller/uninstaller.exe links view/view.exe links wcmd/wcmd.exe links winefile/winefile.exe links winemine/winemine.exe links winepath/winepath.exe links winhelp/winhelp.exe links winhelp/hlp2sgml.exe links winver/winver.exe links winhelp.exe links server/ context_i386.c has compile error (You must implement get/set_thread_context for your platform) tools/ bin2res.exe links fnt2bdf.exe links makedep.exe links widl/widl.exe links winebuild/winebuild.exe links winedump/winedump.exe links wmc/wmc.exe links wpp/libwpp.a links wrc/wrc.exe links unicode/ libwine_unicode.dll links libwine_unicode.a links

2 3

RE: Missing SignalObjectAndWait
by Sean Mitchell Nov. 28, 2002

Nov. 28, 2002

> I think that the first problem is that if foo.exe.so links with > libpthread.so, then libpthread.so gets loaded and initialized before > ntdll.dll.so is loaded and overrides the pthread functions in the C > library -> big trouble. > > This migh conceivable be worked around using a wrapper like I > described > for libmfc.so except this time the wrapper would just load libntdll.so > and the wrapped executable would link with libpthread.so. > > Then I guess it should work since threaded opengl libraries > are supposed > to work. > > But is there really an advantage to using pthread rather than > the Win32 > threading functions when porting a Windows application? After all one > should not have to change the code when porting with Winelib... Without SignalObjectAndWait() I imagine that many medium sized to large apps would have to consider alternative threading libraries... the app I'm trying to port uses it quite a bit to prevent race conditions. As an interested party rather than a developer I'd suggest that the effort would be best spent implementing SignalObjectAndWait() before worrying about pthread compatibility, but I don't know the extent of the work involved. For my own porting project I'm now considering at a "clean" port without any Windows calls - fortunately we only use the thread calls and some file system calls from the Win32 API - but I suspect that this might present a roadblock to other projects hoping for a painless port. In any case, you folks have done a great job with Wine and winelib, and I thank you for it. Cheers, Sean

1 0