http://bugs.winehq.org/show_bug.cgi?id=7929
------- Additional Comments From the3dfxdude(a)gmail.com 2007-03-05 12:26 -------
This problem seems to be cause by incorrect network settings that I cover in
both my HOWTOs
Diablo 2 uses gethostbyname()...:
http://appdb.winehq.org/appview.php?iVersionId=49
"If you are going to play a direct TCP/IP game and the game tells you that it
could not detect a valid address, make sure about things:
1. Have a valid internet addressable IP address for internet play or proper
NAT forwarding.
2. Have a hostname other than localhost.
3. In /etc/hosts, have a valid hostname of your computer listed with your
current IP address you want to use and do not have your hostname listed with
127.0.0.1. Do not have "localhost 127.0.0.1" listed first either."
Warcraft III uses broadcast packets...:
http://appdb.winehq.org/appview.php?iVersionId=3126
"If you try to play using the Local Area Network option, and do not see a game
hosted from your machine on another or vice versa, and you are in the same
subnet, this is likely caused by not having a default gateway. The game relies
on sending UDP packets to the broadcast address and Linux will not send them
unless there is a default gateway or another rule to handle them. To fix it,
there are two methods:
Add a default gateway.
- OR -
Route 255. 255. 255. 255 to your local network.
See Wine Traffic #62 http://www.winehq.org/?issue=62 for another description of
the issue. This is not considered a bug."
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Upgraded to 0.9.36 and Still doesn't work.
Application is SAINT StratUp professional from
http://www.saintnet.com/download.html
installer file is startup.exe, and application executable file is also
named startup.exe
terminal output below:
[adolfo@dc85d14fb ~]$ wine --version
wine-0.9.36
[adolfo@dc85d14fb ~]$ wine /home/adolfo/startup.exe
Xlib: extension "XFree86-DRI" missing on display ":93.0".
Xlib: extension "XFree86-DRI" missing on display ":93.0".
Xlib: extension "XFree86-DRI" missing on display ":93.0".
fixme:system:SystemParametersInfoW Unimplemented action: 8202
(SPI_GETFONTSMOOTHINGTYPE)
fixme:system:SystemParametersInfoW Unimplemented action: 8202
(SPI_GETFONTSMOOTHINGTYPE)
fixme:system:SystemParametersInfoW Unimplemented action: 8202
(SPI_GETFONTSMOOTHINGTYPE)
Xlib: extension "XFree86-DRI" missing on display ":93.0".
Xlib: extension "XFree86-DRI" missing on display ":93.0".
[adolfo@dc85d14fb ~]$ wine c:\\StartUp\\startup.exe
Xlib: extension "XFree86-DRI" missing on display ":93.0".
Xlib: extension "XFree86-DRI" missing on display ":93.0".
fixme:win:GetProcessDefaultLayout ( 0x33f1b0 ): No BiDi
fixme:keyboard:X11DRV_ActivateKeyboardLayout 0x4090409, 0000: stub!
fixme:keyboard:X11DRV_ActivateKeyboardLayout 0x4090409, 0000: stub!
fixme:keyboard:X11DRV_ActivateKeyboardLayout 0x4090409, 0000: stub!
fixme:keyboard:X11DRV_ActivateKeyboardLayout 0x4090409, 0000: stub!
[adolfo@dc85d14fb ~]$
and then a popup window with a message like "Error: The file does not
exist, creating E:\TEMDETMOV.TPS Path doesn't exist, press OK to leave
application"
Regards,
Angel Parrales
P.S.: apologize for my shift key in the previous message.
Wine Bugs wrote:
> http://bugs.winehq.org/show_bug.cgi?id=8247
>
>
> vitaliy(a)kievinfo.com changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Severity|major |normal
> Component|wine-files |wine-misc
> Priority|P4 |P2
>
>
>
>
> ------- Additional Comments From vitaliy(a)kievinfo.com 2007-01-05 20:47 -------
> You are using really old Wine version - upgrade!
> What is the name of the application?
>
> And you SHIFT KEY STUCK >>>>.. phew mine did too - it's contagious!
>
>
http://bugs.winehq.org/show_bug.cgi?id=8234
truiken(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|wine-msi |wine-misc
------- Additional Comments From truiken(a)gmail.com 2007-03-05 12:09 -------
Nothing in the log leads me to think it's a bug in msi.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8266
------- Additional Comments From juan_lang(a)yahoo.com 2007-03-05 11:38 -------
Also, I'm not certain whether you need to install DCOM98. You might try running
regsvr32 vbscript.dll, and running with builtin ole32, oleaut32.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8266
------- Additional Comments From juan_lang(a)yahoo.com 2007-03-05 11:26 -------
Could you also log a separate bug for the error when you run it with native
crypt32/rsaenh?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8269
Summary: GetFileSecurityW() regression: does not work for
directories
Product: Wine
Version: 0.9.36.
Platform: All
OS/Version: other
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: wine-files
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
there seems to be a regression introduced due to recent GetFileSecurityW rewrite.
Some apps, for instance native msi service die on this.
--- snip trace ---
0019:Call advapi32.GetFileSecurityW(0018dbd4
L"c:\\windows\\Installer",00000001,61752264,00000040,61752244) ret=74651fd1
trace:file:CreateFileW L"c:\\windows\\Installer" GENERIC_READ FILE_SHARE_READ
creation 3 attributes 0x0
trace:file:RtlDosPathNameToNtPathName_U
(L"c:\\windows\\Installer",0x61752120,(nil),(nil))
trace:file:RtlGetFullPathName_U (L"c:\\windows\\Installer" 520 0x61751e74 (nil))
trace:ntdll:NtCreateFile handle=0x61752128 access=80000000
name=L"\\??\\C:\\windows\\Installer" objattr=00000040 root=(nil) sec=(nil)
io=0x61752118 alloc_size=(nil)
attr=00000000 sharing=00000001 disp=1 options=00000050 ea=(nil).0x00000000
trace:file:wine_nt_to_unix_file_name L"\\??\\C:\\windows\\Installer" ->
"/home/focht/.wine/dosdevices/c:/windows/Installer"
warn:file:CreateFileW Unable to create file L"c:\\windows\\Installer" (status
c00000ba)
trace:file:CreateFileW returning 0xffffffff
0019:Ret advapi32.GetFileSecurityW() retval=00000000 ret=74651fd1
0019:Call kernel32.GetLastError() ret=7471d86d
0019:Ret kernel32.GetLastError() retval=00000005 ret=7471d86d
--- snip trace ---
GetFileSecurityW() calls CreateFileW() with attributes = 0
In CreateFileW() before the call to NtCreateFile() is made, the options are set
by following snippet:
--- snip dlls/kernel32/file.c CreateFileW() ---
options = 0;
if (attributes & FILE_FLAG_BACKUP_SEMANTICS)
options |= FILE_OPEN_FOR_BACKUP_INTENT;
else
options |= FILE_NON_DIRECTORY_FILE;
...
--- snip dlls/kernel32/file.c CreateFileW() ---
This has severe consequences (at least on NT based systems).
With the FILE_NON_DIRECTORY_FILE flag set, NtCreateFile() returns
STATUS_FILE_IS_A_DIRECTORY because it encounters a folder ("c:\windows\installer")
This status is later remapped to "access denied" (0x5)
Calling CreateFileW() with that flags is expected behaviour and works like windows.
To get GetFileSecurityW() work for directories too, CreateFileW *must* must be
called with FILE_FLAG_BACKUP_SEMANTICS flag as file attributes.
That way CreateFileW() will succeed, returning a handle to directory on NT based
systems.
Leave Windows 95/98/ME alone (unsupported flag, Microsoft calls it 'broken').
So to fix this regression, add the FILE_FLAG_BACKUP_SEMANTICS flag to attributes
when calling CreateFileW():
--- snip dlls/advapi/security.c ---
BOOL WINAPI GetFileSecurityW( LPCWSTR lpFileName,
SECURITY_INFORMATION RequestedInformation,
PSECURITY_DESCRIPTOR pSecurityDescriptor,
DWORD nLength, LPDWORD lpnLengthNeeded )
{
...
hfile = CreateFileW( lpFileName, GENERIC_READ, FILE_SHARE_READ,
NULL, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, 0 );
if ( hfile == INVALID_HANDLE_VALUE)
return FALSE;
...
}
--- snip dlls/advapi/security.c ---
CreateFileW is now called with FILE_FLAG_BACKUP_SEMANTICS attributes set.
Works for file and directories.
Trace with patched GetFileSecurityW():
--- snip trace ---
000e:Call advapi32.GetFileSecurityW(0018dbd4
L"c:\\windows\\Installer",00000001,60c47264,00000040,60c47244) ret=74651fd1
trace:file:CreateFileW L"c:\\windows\\Installer" GENERIC_READ FILE_SHARE_READ
creation 3 attributes 0x2000000
trace:file:RtlDosPathNameToNtPathName_U
(L"c:\\windows\\Installer",0x60c47120,(nil),(nil))
trace:file:RtlGetFullPathName_U (L"c:\\windows\\Installer" 520 0x60c46e74 (nil))
trace:ntdll:NtCreateFile handle=0x60c47128 access=80000000
name=L"\\??\\C:\\windows\\Installer" objattr=00000040 root=(nil) sec=(nil)
io=0x60c47118 alloc_size=(nil)
attr=00000000 sharing=00000001 disp=1 options=00004010 ea=(nil).0x00000000
trace:file:wine_nt_to_unix_file_name L"\\??\\C:\\windows\\Installer" ->
"/home/focht/.wine/dosdevices/c:/windows/Installer"
trace:file:CreateFileW returning 0x70
fixme:ntdll:NtQuerySecurityObject
(0x70,0x00000001,0x60c47264,0x00000040,0x60c47244) stub!
trace:ntdll:NtQuerySecurityObject len=36
000e:Ret advapi32.GetFileSecurityW() retval=00000001 ret=74651fd1
--- snip trace ---
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=7892
------- Additional Comments From juan_lang(a)yahoo.com 2007-03-05 11:08 -------
Hi Anastasius,
yes, you're probably right: it would be better to unload the DLLs I've loaded
when wintrust is unloaded, rather than force them to be unloaded when the
process exits. In fact, crypt32 also needs this, for CryptSIPLoad and
CryptGetOIDFunctionAddress.
Question for you:
--- quote ---
- get around CertComparePublicKeyInfo() checks by adjusting the public key info
after cert creation to match the client one (couldnt find an easy way with
CertCreateSelfSignCertificate without rewriting/dup all the code)
--- quote ---
Could you elaborate? I suspect there's a bug in CertCreateSelfSignCertificate,
so I was wondering whether that's what you're seeing.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8234
------- Additional Comments From tehstealth(a)yahoo.com 2007-03-05 10:58 -------
Created an attachment (id=6107)
--> (http://bugs.winehq.org/attachment.cgi?id=6107&action=view)
Supcom install - WINEDEBUG=+msi,+msidb,+file wine 'D:/setup.exe' >& ~/msi.log
This thing is huge, but I can't find any significant error at the end. I
guessed msi because it was during the install, but I guessed as to the affected
component since I wasn't sure.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8268
Summary: REALPOPUP network messenger installed but not running
Product: Wine
Version: 0.9.29.
Platform: Other
URL: http://www.matro.it/site/show/english/realpopup.aspx
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-console
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: mchiavegatti(a)uol.com.br
The installation process for the REALPOPUP went fine but when opened it does not
see any user in the network. Actually it does not recognize any network.
I already copied all the .DLL files to the WIN/SYSTEM32 folder created in the
virtual C drive.
Any information on how to proceed will be appreciated.
TKS.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8265
------- Additional Comments From matevz.jekovec(a)gmail.com 2007-03-05 10:22 -------
It's a command executed in Makefile chain. And it works fine using the
WindowsXP's cmd.exe shell. So it's definitely the && not yet implemented. Thanks.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.