SJphone crashing
Hi!
I would like to test a free softphone application called "SJphone" (free
download from http://www.sjlabs.com ). I know there is a native Linux version,
but it's much less featured than the windows one (mainly missing skin support
and generally less options) and because I need to train other users how to use
the windows version, I have to try it for myself first :-).
Installation is working well, no errors encountered. However, after trying to
run the program, its GUI appered for a while with a sandclock cursor and then
the following crash occured.
I don't have access to real windows so I don't have any windows DLLs
available. Would it be possible to fix wine's ones to make the program working ?
With regards, Pavel Troller
P.S. running CVS wine from 06/01/15 (yesterday).
[EMAIL PROTECTED]:~/.wine/drive_c/Program Files/SJLabs/SJphone$ wine SJphone.exe
err:wave:OSS_WaveOutInit open(/dev/mixer2) failed (No such file or directory)
err:wave:OSS_WaveInInit open(/dev/mixer2) failed (No such file or directory)
fixme:ole:CoRegisterMessageFilter stub
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7ff51ee8)->((nil),0008)
fixme:ras:RasEnumConnectionsA (0x7f7b10a0,0x7fc68e34,0x7fc68e40),stub!
fixme:ras:RasEnumConnectionsA RAS support is not implemented! Configure program
to use LAN connection/winsock instead!
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7ff64d48)->((nil),0008)
err:ole:CoGetClassObject class {4955dd33-b159-11d0-8fcf-00aa006bcc59} not
registered
err:ole:CoGetClassObject no class object {4955dd33-b159-11d0-8fcf-00aa006bcc59}
could be created for for context 0x1
fixme:ole:CoCreateInstance no classfactory created for CLSID
{4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154
fixme:win:LockWindowUpdate (0x2002a), partial stub!
fixme:win:LockWindowUpdate ((nil)), partial stub!
fixme:keyboard:RegisterHotKey (0x2002a,1,0x0006,81): stub
fixme:keyboard:RegisterHotKey (0x2002a,2,0x0006,66): stub
fixme:keyboard:RegisterHotKey (0x2002a,3,0x0006,76): stub
fixme:keyboard:RegisterHotKey (0x2002a,4,0x0006,78): stub
fixme:keyboard:UnregisterHotKey (0x2002a,5): stub
fixme:keyboard:RegisterHotKey (0x2002a,6,0x0006,83): stub
fixme:keyboard:RegisterHotKey (0x2002a,7,0x0006,77): stub
err:msacm:MSACM_GetRegistryKey No alias needed for registry entry
wine: Unhandled page fault on write access to 0x59be at address 0x3f6dbd50
(thread 0009), starting debugger...
WineDbg starting on pid 0x8
Unhandled exception: page fault on write access to 0x59be in 32-bit code
(0x3f6dbd50).
In 32 bit mode.
Register dump:
CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033
EIP:3f6dbd50 ESP:7fc68248 EBP:7fc689ec EFLAGS:00210246( - 00 -RIZP1)
EAX:015000d4 EBX:3f6e4e04 ECX:209c EDX:54da0020
ESI:009c7ffc EDI:7fa403d0
Stack dump:
0x7fc68248: 7fc68250 7fa40408 0078 009c7ffc
0x7fc68258: 015000d4 00d700d6 016e0158 017000da
0x7fc68268: 00dd00dc 00df0162 00e10155 010300e2
0x7fc68278: 013a00e4 00e70107 00e9010d 00eb0119
0x7fc68288: 00ed011b 010f00ee 01440111 00f30148
0x7fc68298: 015100f4 00f700f6 016f0159 017100fa
Backtrace:
=>1 0x3f6dbd50 in msacm32 (+0xbd50) (0x3f6dbd50)
2 0x3f6dc2d9 MSACM_RegisterDriver+0x139 in msacm32 (0x3f6dc2d9)
3 0x3f6d88fb acmDriverAddA+0x4b in msacm32 (0x3f6d88fb)
4 0x0057dea5 in sjphone (+0x17dea5) (0x0057dea5)
5 0x (0x)
6 0x005781e0 in sjphone (+0x1781e0) (0x005781e0)
0x3f6dbd50: movl%eax,0x0(%edx,%esi,8)
Modules:
Module Address Debug info Name (131 modules)
PE 0x0040-0085e000 Export sjphone
PE 0x1000-10006000 Deferredmozctlx
ELF 0x2000-20015000 Deferredld-linux.so.2
ELF 0x20015000-2002f000 Deferredlibwine.so.1
ELF 0x2002f000-2004 Deferredlibpthread.so.0
ELF 0x2004-20149000 Deferredlibc.so.6
ELF 0x20149000-2014c000 Deferredlibdl.so.2
ELF 0x2014c000-20169000 Deferrediphlpapi
\-PE 0x2015-20169000 \ iphlpapi
ELF 0x20169000-201af000 Deferredrpcrt4
\-PE 0x2018-201af000 \ rpcrt4
ELF 0x201af000-20257000 Deferredcomctl32
\-PE 0x201c-20257000 \ comctl32
ELF 0x20257000-202e3000 Deferredoleaut32
\-PE 0x2027-202e3000 \ oleaut32
ELF 0x202e3000-202fb000 Deferredversion
\-PE 0x202f-202fb000 \ version
ELF 0x202fb000-20374000 Deferredwinex11
\-PE 0x2031-20374000 \ winex11
ELF 0x20374000-2037a000 Deferredlibxxf86dga.so.1
ELF 0x2037a000-2038 Deferredlibxxf86vm.so.1
ELF 0x2038-2039 Deferredlibxext.so.6
ELF 0x2039-20393000 Deferredxlcdef.so.2
ELF 0x20393000-203af000 Deferredimm32
\-PE 0x203a-203af000
Re: dlls/wined3d/device.c GetCreationParameters
Al Tobey gmail.com> writes:
>
> Ack, after thinking about it and talking with people on IRC, I think I
> did the wrong thing. New patch attached that just copies the
> parameters one-by-one to the passed-in struct. Both methods work,
> though, so this probably needs to be tested on Windows.
>
> In any case, this one is probably safest for now.
> -Al Tobey
Interesting that your original patch made things work at all... you set the
pParameters variable, which is then promptly forgotten upon return from the
function. In effect your original patch does nothing... so why it would make
things work is beyond me :)
In any case, your second patch looks much better, but as Robert said, can't you
simplify it with a memcpy() instead of an exhaustive list of the structure
members? That is, assuming This->createParms and pParameters are of the same
type you could just do:
{
...
memcpy(pParameters, &This->createParms,
sizeof(D3DDEVICE_CREATION_PARAMETERS));
return D3D_OK;
}
This is much less error-prone than a list of structure members.
Regards,
Aric
Re: shell32: Add the right SHFileOperation flags to fix some failing test on windows
James Hawkins wrote: Changelog: * Add the right SHFileOperation flags to fix some failing tests on windows. * Add a newline to the end of the file to avoid a warning. dlls/shell32/tests/shlfileop.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) This causes a number of MessageBoxes to appear during the tests for me: "OverWrite File testdir2\test1.txt?" "OverWrite File testdir2\test2.txt?" "OverWrite File testdir2\test3.txt?" "OverWrite File testdir2\a.txt?" "OverWrite File testdir2\b.txt?" "OverWrite File testdir2\test4.txt\a.txt?" "OverWrite File testdir2\test1.txt?" "OverWrite File testdir2\test4.txt\a.txt?" "OverWrite File testdir2\a.txt?" Answering OK to each one lets the tests pass, but I don't think we want these tests to be interactive. Mike
Re: shell32: Reimplement a factored SHFileOperation [RESEND]
James Hawkins wrote: This version initializes all memory so we don't crash when freeing the file list, as spotted by Mike. I also corrected the return types from int to HRESULT. Changelog: * Reimplement a factored SHFileOperation. Hey James, Great work, but the tests still fail for me: make[1]: Entering directory `/home/mike/wine/dlls/shell32/tests' ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlfileop.c && touch shlfileop.ok shlfileop.c:707: Test failed: Files and directories are moved to directory shlfileop.c:708: Test failed: The file is moved shlfileop.c:709: Test failed: The directory is moved shlfileop.c:710: Test failed: The file in subdirectory is moved Mike
Re: Debugging a null pointer dereference
Marcus Meissner wrote: On Sat, Jan 14, 2006 at 08:41:50PM +0100, Christer Palm wrote: After messing around with with the mfc42 runtime, I managed to get a backtrace with debugging information, which looks like this: =>1 0x5f4056dd CEnumOleVerb::~CEnumOleVerb+0x37 [oleverb.cpp:61] in mfc42 (0x5f4056dd) You should find out what it does before. Capture a WINEDEBUG=+relay,+seh trace (redirect output to a logfile). Then look at this trace, search for the winedbg call and scroll back until the RaiseException with c0005 code (likely only some dozen lines above the initial debugger start). The look backwards from this to see where it might have got this NULL pointer... :/ If its bad, it could have got it from millions of lines ago. :/ Hello Marcus and thanks for your response! OK, sounds a bit ad-hoc to me but I'm sure that you're talking from experience. In the relay trace, I can see that just before the exception is raised, it sits in a loop calling: 0009:Call user32.ShowWindow(,) ret=5f4056f5 0009:Ret user32.ShowWindow() retval= ret=5f4056f5 33 times (same return address each time), which looks a bit suspicious to me (HWND being 0). The return address is in MFC42, but as winedbg refuses to run the dang thing I can't resolve that into the actual MFC function or set any breakpoints or anything. So, looking a bit further up in the trace, my best bet is that it's getting that HWND from: 0009:Call user32.GetParent(00010026) ret=5f401281 ... 0009:Ret user32.GetParent() retval= ret=5f401281 But that's just a wild guess. 00010026 seems to the apps main window, because I see a lot of activity on that HWND before the crash - for example: 0009:Call user32.DrawMenuBar(00010026) ret=5f4136d0 ... 0009:Ret user32.DrawMenuBar() retval=0001 ret=5f4136d0 And I can see the menu bar of the main (top) window being updated just before the crash. I played around a bit with the graphics settings in winecfg with no result other than that I've now managed to lock myself out of wine (including winecfg) by specifying an invalid display depth :-( Does anyting of this make sense? Cheers, -- Christer Palm
Re: dlls/wined3d/device.c GetCreationParameters
Al Tobey wrote:
HRESULT WINAPI IWineD3DDeviceImpl_GetCreationParameters(IWineD3DDevice
*iface, D3DDEVICE_CREATION_PARAMETERS *pParameters) {
IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *) iface;
-
-FIXME("(%p) : stub\n", This);
-/* Setup some reasonable defaults */
-pParameters->AdapterOrdinal = 0; /* always for now */
-pParameters->DeviceType = D3DDEVTYPE_HAL; /* always for now */
-pParameters->hFocusWindow = 0;
-pParameters->BehaviorFlags =0;
+pParameters = &This->createParms;
+FIXME("(%p) : Partially implemented ... probably needs some checks\n",
This);
return D3D_OK;
}
This doesn't do what you think it does. pParameters is a local variable
to assigning it to something won't affect what the caller sees. You
probably want to use memcpy.
--
Rob Shearman
Re: Static control [10/10]: Support the Windows XP mode of the static control
An even better summary is in WWN 243: http://www.winehq.org/site?issue=243#Button%20Code%20Audit
Re: Static control [10/10]: Support the Windows XP mode of the static control
Hi Filip, This doesn't seem right. User32 shouldn't be checking manifests, I would expect the STATIC control to be subclassed in COMCTL32 and the WinXP functionality implemented there. You're right, but it's not easy to implement it in the same way as Windows does. Windows has two implementations of the basic controls, one in user32.dll and one in comctl32.dll (as summarized in WWN 267: http://www.winehq.org/site?issue=267#Theming%20Revisited ). The controls in comctl32.dll contain the Windows XP version of the controls, user32.dll contains the controls that are compatible with older versions of Windows. I've discovered that applications which contain a manifest use the controls from comctl32.dll even if they don't link to that file (even if they don't call InitCommonControls). I've got a test application that just displays an edit box with the ES_PASSWORD style, which shows asterisks (old edit control in user32) or black circles (new edit control in comctl32). The test application has a manifest, so it displays black circles and uses themes even if it never calls InitCommonControls. If themes are disabled, Windows XP still displays the edit box with the black circles and doesn't fall back to the old controls. So I agree that I've not implemented it the same way as Windows, but implementing it the same way would be difficult because we need two versions of the edit and the static control and detect at the right time which version to use. Regards Michael
Re: winehq on osx-intel?
On 1/15/06, Bob Hunter <[EMAIL PROTECTED]> wrote: > Hello, > > There are winehq binaries for unix except osx unix, > being apple mac os. > As Apple shifted to intel cpu, winehq has one more > platform to go. The > old VirtualPC by connectix was purchased by microsoft, > and there are > no news about its conversion to the new platform. > Further, no one really > wants to run an emulation of the windows desktop. Are > there any plans > to extend winehq to osx, possibly for a fee? I would > be happy to pay for > a copy. > http://www.macworld.com/news/2005/06/22/crossover/index.php -- James Hawkins
Re: Problem with older wgl patch
Tomas Carnecky <[EMAIL PROTECTED]> writes: > Just tried latest version from git and the compilation fails because > 'type' is undefined. How often is git updated from CVS? Or do the > developers check-in directly into git? Yes, I commit directly into git. All commits are immediately mirrored into CVS, so 'latest git' and 'latest cvs' are always the same thing. -- Alexandre Julliard [EMAIL PROTECTED]
Re: user: Implement scrolling in popup menus
Hi, Anything wrong with that patch? (Yes I know that separate arrow bitmaps should be used instead of the scrollbar ones. But I can't draw ;) On Sat, 7 Jan 2006 16:54:15 +0300 Phil Krylov <[EMAIL PROTECTED]> wrote: > ChangeLog: > > Added scrolling support to popup menus which don't fit on the desktop. -- Ph.
Re: Repackaging Mozilla ActiveX control to include MSVCP60.DLL?
On 1/15/06, Ge van Geldorp <[EMAIL PROTECTED]> wrote: > > The Mozilla ActiveX control download feature is cool and all, > > but until we repackage the sucker to include MSVCP60.DLL to fix > > http://bugs.winehq.org/show_bug.cgi?id=4064 ... > > I could have sworn I saw somebody post a note saying they had > > done said repackaging, but I can't find it now... > > http://www.winehq.org/pipermail/wine-patches/2005-December/022795.html > Instructions on how to repackage can be found at > svn://svn.reactos.org/trunk/tools/MozillaControl/ Thanks! I've updated bug 4064. Now can somebody update winehq.org's copy of the control so we can close that bug? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Repackaging Mozilla ActiveX control to include MSVCP60.DLL?
Dan Kegel wrote: The Mozilla ActiveX control download feature is cool and all, but until we repackage the sucker to include MSVCP60.DLL to fix http://bugs.winehq.org/show_bug.cgi?id=4064 it's going to leave a lot of users scratching their heads as to why it keeps asking where its files are. I could have sworn I saw somebody post a note saying they had done said repackaging, but I can't find it now... http://svn.reactos.org/viewcvs/trunk/tools/MozillaControl/ http://sourceforge.net/project/showfiles.php?group_id=6553&package_id=172179 http://www.reactos.org/archives/public/ros-dev/2005-December/006771.html - Filip
winehq on osx-intel?
Hello, There are winehq binaries for unix except osx unix, being apple mac os. As Apple shifted to intel cpu, winehq has one more platform to go. The old VirtualPC by connectix was purchased by microsoft, and there are no news about its conversion to the new platform. Further, no one really wants to run an emulation of the windows desktop. Are there any plans to extend winehq to osx, possibly for a fee? I would be happy to pay for a copy. Bob __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: Repackaging Mozilla ActiveX control to include MSVCP60.DLL?
> From: Boaz Harrosh > > Hi! I was Just wondering. Is there at all a MinGW build > system for the "Mozilla ActiveX control"? I guess not so the > Question is: > Any body knows what are the Main hurdles for that? Is that mainly COM > TLB(s) related? or there are other problems? I've built Firefox with MinGW, but never tried to rebuild the control (I only repackaged it). GvG
Re: Problem with older wgl patch
Aric Cyr wrote: Tim Savannah gmail.com> writes: + DWORD type = GetObjectType(hdc);where that patch placed it in the file allows opengl to work again. I think this is fixed in CVS already. Which version of wine are you trying with? Try out the latest CVS if you can. Just tried latest version from git and the compilation fails because 'type' is undefined. How often is git updated from CVS? Or do the developers check-in directly into git? tom
Re: Repackaging Mozilla ActiveX control to include MSVCP60.DLL?
Boaz Harrosh wrote: Hi! I was Just wondering. Is there at all a MinGW build system for the "Mozilla ActiveX control"? I guess not so the Question is: Any body knows what are the Main hurdles for that? Is that mainly COM TLB(s) related? or there are other problems? There's a bug in Mozilla.org's bugzilla [1] to get Mozilla to compile with GCC/MingW on Windows, which is a related problem. One problem is that there's currently no working open source replacement for MIDL.EXE, though Wine's widl seems to be improving gradually thanks mainly to Rob's work. Mike [1] https://bugzilla.mozilla.org/show_bug.cgi?id=203303
Re: Repackaging Mozilla ActiveX control to include MSVCP60.DLL?
Hi! I was Just wondering. Is there at all a MinGW build system for the "Mozilla ActiveX control"? I guess not so the Question is: Any body knows what are the Main hurdles for that? Is that mainly COM TLB(s) related? or there are other problems? Ge van Geldorp wrote: From: Dan Kegel The Mozilla ActiveX control download feature is cool and all, but until we repackage the sucker to include MSVCP60.DLL to fix http://bugs.winehq.org/show_bug.cgi?id=4064 it's going to leave a lot of users scratching their heads as to why it keeps asking where its files are. I could have sworn I saw somebody post a note saying they had done said repackaging, but I can't find it now... http://www.winehq.org/pipermail/wine-patches/2005-December/022795.html Instructions on how to repackage can be found at svn://svn.reactos.org/trunk/tools/MozillaControl/ GvG
RE: Repackaging Mozilla ActiveX control to include MSVCP60.DLL?
> From: Dan Kegel > > The Mozilla ActiveX control download feature is cool and all, but > until we repackage the sucker to include MSVCP60.DLL to fix > http://bugs.winehq.org/show_bug.cgi?id=4064 > it's going to leave a lot of users scratching their heads as to why it > keeps asking where its files are. > > I could have sworn I saw somebody post a note saying they had done > said repackaging, but I can't find it now... http://www.winehq.org/pipermail/wine-patches/2005-December/022795.html Instructions on how to repackage can be found at svn://svn.reactos.org/trunk/tools/MozillaControl/ GvG
Re: Debugging a null pointer dereference
On Sat, Jan 14, 2006 at 08:41:50PM +0100, Christer Palm wrote: > Hi! > I'm new to this list, but a long time Wine user and regular WWN reader. > > The other day I decided to try out Semiolog, a free as-in-beer piece of > software to create labels from electric equipment manufacturer Hager, > under wine. The software can be downloaded from here: > http://www.hager.se/files/download/0/482_1/0/SemiologSue40a.exe > > Unfortunately it doesn't work. So although I haven't been doing any > Windows programming in the last 15 years I decided to try to do > something useful and try find out why it doesn't work. I figured that > this application would be a good thing to try to get to work as it is > supposedly rather trivial. > > So what follows is a description of a newbies attempt at some wine > debugging: > > > The application installs and starts up just fine, but when I try to > create a new document, I get a null pointer dereference in mfc42.dll. > > After messing around with with the mfc42 runtime, I managed to get a > backtrace with debugging information, which looks like this: > =>1 0x5f4056dd CEnumOleVerb::~CEnumOleVerb+0x37 [oleverb.cpp:61] in > mfc42 (0x5f4056dd) You should find out what it does before. Capture a WINEDEBUG=+relay,+seh trace (redirect output to a logfile). Then look at this trace, search for the winedbg call and scroll back until the RaiseException with c0005 code (likely only some dozen lines above the initial debugger start). The look backwards from this to see where it might have got this NULL pointer... :/ If its bad, it could have got it from millions of lines ago. :/ Ciao, Marcus
Re: Repackaging Mozilla ActiveX control to include MSVCP60.DLL?
--- Begin Message --- Dan Kegel wrote: The Mozilla ActiveX control download feature is cool and all, but until we repackage the sucker to include MSVCP60.DLL to fix http://bugs.winehq.org/show_bug.cgi?id=4064 it's going to leave a lot of users scratching their heads as to why it keeps asking where its files are. I could have sworn I saw somebody post a note saying they had done said repackaging, but I can't find it now... http://svn.reactos.org/viewcvs/trunk/tools/MozillaControl/ http://sourceforge.net/project/showfiles.php?group_id=6553&package_id=172179 http://www.reactos.org/archives/public/ros-dev/2005-December/006771.html - Filip --- End Message ---
