http://bugs.winehq.org/show_bug.cgi?id=13487
Summary: Smartftp does not run (dogfood) Product: Wine Version: 1.0-rc2 Platform: PC URL: http://www.smartftp.com/ OS/Version: Linux Status: NEW Keywords: download Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: austinenglish@gmail.com
Created an attachment (id=13410) --> (http://bugs.winehq.org/attachment.cgi?id=13410) Terminal output in git
Reported in wine-users:
SmartFTP installs but fails to start with: "Fatal Error: sfFTPLib.dll is not registered correctly"
http://www.smartftp.com/download/
System: Fedora 9 Wine: 1.0 rc2
Gave it a try. Installs fine, after installing, running regsvr32 on sfFTPLib.dll gets it to run a bit, then installs wine gecko. Runs a bit more, then crashes. Terminal output and backtrace attached.
http://bugs.winehq.org/show_bug.cgi?id=13487
--- Comment #1 from Austin English austinenglish@gmail.com 2008-05-27 16:01:54 --- Created an attachment (id=13411) --> (http://bugs.winehq.org/attachment.cgi?id=13411) Backtrace in current git
Obtained from winedbg> bt all
http://bugs.winehq.org/show_bug.cgi?id=13487
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com Severity|enhancement |normal Summary|Smartftp does not run |Smartftp dies on startup, |(dogfood) |complaining that | |sfFTPLIB.dll not registered | |(dogfood)
--- Comment #2 from Dan Kegel dank@kegel.com 2008-05-30 13:48:48 --- The appdb didn't have much info: http://appdb.winehq.org/objectManager.php?sClass=application&iId=1295 but bug 12461 has a hint: setting win2k mode gets past the problem. I looked into this more. Setting win2k during install doesn't help; it's during first run that it matters, evidently somehow on first run, that dll gets registered properly in win2k mode. (That makes this a kind of regression, since we only recently switched to winxp as the default.)
Let's make this bug about the DLL registration. The later crash after Gecko installs is probably a shortcoming in our mshtml, and deserves a second bug report. (BTW the app can't install with ies4linux, tried.)
http://bugs.winehq.org/show_bug.cgi?id=13487
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |baryluk@smp.if.uj.edu.pl
--- Comment #3 from Juan Lang juan_lang@yahoo.com 2008-06-04 13:10:39 --- *** Bug 13677 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=13487
--- Comment #4 from Austin English austinenglish@gmail.com 2008-11-23 22:53:34 --- Still present in git.
http://bugs.winehq.org/show_bug.cgi?id=13487
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |8018
http://bugs.winehq.org/show_bug.cgi?id=13487
Tomasz Sałaciński tsalacinski@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tsalacinski@gmail.com
--- Comment #5 from Tomasz Sałaciński tsalacinski@gmail.com 2009-05-14 08:54:42 --- Still present in WINE 1.1.21
http://bugs.winehq.org/show_bug.cgi?id=13487
--- Comment #6 from Stefan Leichter Stefan.Leichter@camLine.com 2009-05-14 16:52:32 --- Putting native hnetcfg.dll into c:\windows\system32 and registering the hnetcfg.dll and sfFTPLib.dll will make the error message "Fatal Error: sfFTPLib.dll is not registered correctly" got away.
The new error message is than "Internal application error" ..
http://bugs.winehq.org/show_bug.cgi?id=13487
--- Comment #7 from Juan Lang juan_lang@yahoo.com 2009-08-14 18:09:14 --- (In reply to comment #6)
Putting native hnetcfg.dll into c:\windows\system32 and registering the hnetcfg.dll and sfFTPLib.dll will make the error message "Fatal Error: sfFTPLib.dll is not registered correctly" got away.
The new error message is than "Internal application error" ..
This is the same behavior when registering sfFTPLib.dll without using a native hnetcfg.dll: the "Fatal Error" becomes an "Internal application error."
http://bugs.winehq.org/show_bug.cgi?id=13487
--- Comment #8 from Austin English austinenglish@gmail.com 2010-01-03 15:18:47 --- Still present.
http://bugs.winehq.org/show_bug.cgi?id=13487
Thomas Spear Speeddymon@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Speeddymon@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=13487
--- Comment #9 from Austin English austinenglish@gmail.com 2011-04-01 20:37:22 CDT --- Still in 1.3.17.
http://bugs.winehq.org/show_bug.cgi?id=13487
--- Comment #10 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2011-06-27 17:49:13 CDT --- Created an attachment (id=35317) --> (http://bugs.winehq.org/attachment.cgi?id=35317) add stub for PSCreateMemoryPropertyStore
I tried SmartFTP in current git.
With the hack below for crypt32.CertCreateSelfSignCertificate (to force other codepath in that function) and the attached stub for prosys.PSCreateMemoryPropertyStore i was able to start SmartFTP. Also i had to manually regsister sfFPLib.dll, so that bug is still present in current git.
Maybe we shold change component to crypt32?
--- a/dlls/crypt32/cert.c +++ b/dlls/crypt32/cert.c @@ -3132,7 +3132,7 @@ PCCERT_CONTEXT WINAPI CertCreateSelfSignCertificate(HCRYPTPROV_OR_NCRYPT_KEY_HAN BOOL ret, releaseContext = FALSE; PCERT_PUBLIC_KEY_INFO pubKey = NULL; DWORD pubKeySize = 0,dwKeySpec = AT_SIGNATURE; - + hProv = 0; TRACE("(%08lx, %p, %08x, %p, %p, %p, %p, %p)\n", hProv, pSubjectIssuerBlob, dwFlags, pKeyProvInfo, pSignatureAlgorithm, pStartTime, pExtensions, pExtensions);
http://bugs.winehq.org/show_bug.cgi?id=13487
--- Comment #11 from Austin English austinenglish@gmail.com 2011-06-27 17:54:39 CDT --- (In reply to comment #10)
Created an attachment (id=35317)
--> (http://bugs.winehq.org/attachment.cgi?id=35317) [details]
add stub for PSCreateMemoryPropertyStore
I tried SmartFTP in current git.
With the hack below for crypt32.CertCreateSelfSignCertificate (to force other codepath in that function) and the attached stub for prosys.PSCreateMemoryPropertyStore i was able to start SmartFTP. Also i had to manually regsister sfFPLib.dll, so that bug is still present in current git.
Maybe we shold change component to crypt32?
This bug is for the dll not being registered, those are separate bugs.
http://bugs.winehq.org/show_bug.cgi?id=13487
Thomas Spear Speeddymon@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks|8018 |
http://bugs.winehq.org/show_bug.cgi?id=13487
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |focht@gmx.net Resolution| |DUPLICATE
--- Comment #12 from Anastasius Focht focht@gmx.net 2012-05-17 15:25:15 CDT --- Hello,
dupe of bug 25340
"sfFTPLib.dll" is a registry-free COM inproc server. It is not supposed to be registered with WinVer >= "Windows XP"
--- snip --- <assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1"> <assemblyIdentity name="sfFTPLib" type="win32" version="3.0.0.0" processorArchitecture="x86"></assemblyIdentity> <description>SmartFTP FTP Library</description> <file name="sfFTPLib.dll" hashalg="SHA1"> <comClass clsid="{026F6EBB-0A23-4585-B2E5-E167B0C34D17}" tlbid="{7A3A786C-EB8C-43B3-BC10-8D09ACF5D195}" description="AES128CTRReadStream Class" threadingModel="Both" progid="sfFTPLib.AES128CTRReadStream"> <progid>sfFTPLib.AES128CTRReadStream.1</progid> </comClass> ... <comClass clsid="{52D6E699-9256-414F-8FCD-F38FDF6AC8EE}" tlbid="{7A3A786C-EB8C-43B3-BC10-8D09ACF5D195}" description="Global Class" threadingModel="Both" progid="sfFTPLib.Global"> <progid>sfFTPLib.Global.1</progid> </comClass> --- snip ---
Assembly manifest from main executable:
--- snip --- <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"><assemblyIdentity name="SmartFTP.Client" type="win32" version="2.0.0.0" processorArchitecture="x86"></assemblyIdentity><description>SmartFTP Client</description><dependency><dependentAssembly><assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" publicKeyToken="6595b64144ccf1df" language="*" processorArchitecture="x86"></assemblyIdentity></dependentAssembly></dependency><dependency><dependentAssembly><assemblyIdentity type="win32" name="sfFTPLib" version="3.0.0.0" language="*" processorArchitecture="x86"></assemblyIdentity></dependentAssembly></dependency><trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"><security><requestedPrivileges><requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel></requestedPrivileges></security></trustInfo><application xmlns="urn:schemas-microsoft-com:asm.v3"><windowsSettings><dpiAware --- snip ---
--- snip --- fixme:actctx:parse_depend_manifests Could not find dependent assembly L"sfFTPLib" (3.0.0.0) --- snip ---
For WinVer <= "Windows 2000" the dll contains typelib/registry part where it gets registered as standard inproc COM server - by design.
Louis' problem -> crypt32.CertCreateSelfSignCertificate() reported in comment #10 is still present, it deserves an own bug.
Regards
*** This bug has been marked as a duplicate of bug 25340 ***
http://bugs.winehq.org/show_bug.cgi?id=13487
Frédéric Delanoy frederic.delanoy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #13 from Frédéric Delanoy frederic.delanoy@gmail.com 2012-05-18 09:51:27 CDT --- Closing DUPLICATE bugs.
http://bugs.winehq.org/show_bug.cgi?id=13487
--- Comment #14 from Juan Lang juan.lang@gmail.com 2012-05-18 12:38:19 CDT --- I'm not sure if I understand the crypt32 problem very well. SmartFTP sometimes crashes on startup for me, with or without Louis's hack. I'm certain Louis's hack is incorrect, and though I'm also pretty sure that crypt32 is broken in CertCreateSelfSignCertificate, I'm not sure how that translates to the application's behavior. Could someone comment, or open a new bug, just to help me understand?
I have a patch that I think corrects crypt32's behavior, but it needs tests that I haven't had a chance to write yet. Helping me know that it actually helps an app would help motivate me :)
http://bugs.winehq.org/show_bug.cgi?id=13487
--- Comment #15 from Anastasius Focht focht@gmx.net 2012-05-18 14:54:48 CDT --- Hello Juan,
--- quote --- I'm also pretty sure that crypt32 is broken in CertCreateSelfSignCertificate, I'm not sure how that translates to the application's behavior. Could someone comment, or open a new bug, just to help me understand?
I have a patch that I think corrects crypt32's behavior, but it needs tests that I haven't had a chance to write yet. Helping me know that it actually helps an app would help motivate me :) --- quote ---
I created bug 30719 to track that issue.
Regards
http://bugs.winehq.org/show_bug.cgi?id=13487
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED CC| |bunglehead@gmail.com Component|-unknown |ntdll Depends on| |25340 Resolution|DUPLICATE |
--- Comment #16 from Anastasius Focht focht@gmx.net 2013-10-31 03:25:50 CDT --- Hello folks,
reopening to track remaining issues...
http://bugs.winehq.org/show_bug.cgi?id=25340#c36
Nikolay Sivov:
--- quote --- I tried SmartFTP myself, and it fails for a different reason - popup complaining that sfFTPLib.dll is not registered is a result of failed assembly lookup, not COM object creation. Could you confirm that attached hack helps?
It happens to use ISOLATIONAWARE_MANIFEST_RESOURCE_ID and we only try CREATEPROCESS_MANIFEST_RESOURCE_ID when looking for a resource. --- quote ---
Regards
http://bugs.winehq.org/show_bug.cgi?id=13487
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEW
--- Comment #17 from Anastasius Focht focht@gmx.net 2013-10-31 03:26:42 CDT --- and confirming ...
http://bugs.winehq.org/show_bug.cgi?id=13487
Bug 13487 depends on bug 25340, which changed state.
Bug 25340 Summary: Multiple apps need support for COM server information from PE manifest a.k.a registration/registry-free COM (Exact Audio Copy (EAC), AliWangWang ...) http://bugs.winehq.org/show_bug.cgi?id=25340
What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
http://bugs.winehq.org/show_bug.cgi?id=13487
--- Comment #18 from Austin English austinenglish@gmail.com 2013-10-31 12:31:06 CDT --- (In reply to comment #16)
Hello folks,
reopening to track remaining issues...
http://bugs.winehq.org/show_bug.cgi?id=25340#c36
Nikolay Sivov:
--- quote --- I tried SmartFTP myself, and it fails for a different reason - popup complaining that sfFTPLib.dll is not registered is a result of failed assembly lookup, not COM object creation. Could you confirm that attached hack helps?
It happens to use ISOLATIONAWARE_MANIFEST_RESOURCE_ID and we only try CREATEPROCESS_MANIFEST_RESOURCE_ID when looking for a resource. --- quote ---
Regards
Yes, works here as well, thanks.
http://bugs.winehq.org/show_bug.cgi?id=13487
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |34844
http://bugs.winehq.org/show_bug.cgi?id=13487
--- Comment #19 from Nikolay Sivov bunglehead@gmail.com 2013-11-04 12:30:37 CST --- Lookup failure looks similar to what happens in bug 18889, it even has a similar patch. I tried to build a simple dll with id 2 resource, and it gets picked up by main exe just fine, so I think a fix is correct, meaning it's ok to check id 2 after id 1 failed - still the order of this check is still to be determined. A test will require a generated dll with resource section.
https://bugs.winehq.org/show_bug.cgi?id=13487
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Blocks|34844 | Resolution|--- |DUPLICATE
--- Comment #20 from Anastasius Focht focht@gmx.net --- Hello folks,
since Nikolay confirmed the issue now being the same as bug 18889 resolving as dupe.
Regards
*** This bug has been marked as a duplicate of bug 18889 ***
https://bugs.winehq.org/show_bug.cgi?id=13487
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #21 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=13487
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|http://www.smartftp.com/ |https://web.archive.org/web | |/20210724115127/https://ido | |wnload.idg.pl/zx/vol2/w95/f | |tp/smartftp/4.0.1245/SFTPMS | |I32.exe?md5=6wxHQVYScmFEMPx | |AO8bIbw&expires=1627128058
-
wine-bugs＠winehq.org -
WineHQ Bugzilla