http://bugs.winehq.org/show_bug.cgi?id=14390
Summary: Gmax 1.2: Fatal Error on Install - Ended Prematurely.
Product: Wine
Version: 1.1.0
Platform: PC-x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P1
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: gaming4jc2(a)yahoo.com
Created an attachment (id=14701)
--> (http://bugs.winehq.org/attachment.cgi?id=14701)
Fatal Error on install.
When installing GMAX 1.2 on WINE 1.1.0 I receive the following errors which are
attached.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=23675
Summary: Portable Apps Platform (beta 5) works under Vista,
Win7, but not Wine’s emulation
Product: Wine
Version: 1.2-rc7
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: joelcsalomon(a)gmail.com
Portable Apps Platform (beta 5, see <http://portableapps.com/node/24258>) gives
me the error “The program PortableAppsPlatform.exe has encountered a serious
problem and needs to close. We are sorry for the inconvenience.” Telling Wine
to mimic Windows XP for this program avoids the crash, but the Platform runs
fine under (real) Windows Vista & 7.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18777
Summary: Wine 1.1.22+ resets customized FontLink when switching
locales
Product: Wine
Version: 1.1.22
Platform: All
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: gdi32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: matthewsage(a)live.com
CC: Paul.Hampson(a)Pobox.com
Created an attachment (id=21546)
--> (http://bugs.winehq.org/attachment.cgi?id=21546)
Regression test that shows the patch that broke the desired functionality
Whenever you switch locales (using the latest Wine dev. version -1.1.22-),
whatever custom Font Linking you have made in the FontLink/SystemLink register
key will be wiped out.
This was tested on Wine 1.1.22, after wiping out ~/.wine
I tested it with the Ubuntu x86_64 binary package from the budgetdedicated
servers, AND after building from source.
Steps to reproduce:
1) Run "regedit"
2) Set some System Font Linking replacements in the
HKLM/Software/Microsoft/Windows NT/CurrentVersion/FontLink/SystemLink register
key (in my case: Tahoma -> VL Gothic, Microsoft Sans Serif -> VLGothic, MS Sans
Serif -> VL Gothic)
3) Run any Win32 application with LANG set to a different locale (in my case,
LANG=ja_JP.UTF-8)
Expected results:
The application is executed, whatever Font Linking you made is visible (which
means that the custom Font Linking I made is respected by Wine).
Actual Results:
The application is executed, whatever Font Linking you made is not visible. If
you run "regedit" again, you'll see that the FontLink/SystemLink key is now
empty.
Workaround:
Always run Wine apps with the same locale (LANG=ja_JP.UTF-8 in my case) - That
would include regedit itself, so that the Font Linking you set up is not wiped
as soon as you run another app with a different locale.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10273
Summary: satisfy SafeDisc 2.x heuristic API analyzer by
"adjusting" API exports/entry statistics of wine
builtins
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: wine-kernel
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Created an attachment (id=8924)
--> (http://bugs.winehq.org/attachment.cgi?id=8924)
Patch which should fix SafeDisc 2.x copy protection api analyzer issue
Hello,
if not interested in technical details goto (2) ;-)
I made this a separate bug report like
http://bugs.winehq.org/show_bug.cgi?id=9925 (SafeDisc 1.x stopper) because
SafeDisc has many flavors that differ in various technical ways and can't be
discussed/handled in a single SafeDisc "metabug" like
http://bugs.winehq.org/show_bug.cgi?id=219
SafeDisc Major version based separation allows better tracking of "completion"
state (1.x/2.x/3.x/4.x).
-----------
(1)
It took me a couple of days to get an idea what SafeDisc 2.x really does with
the API exports and to find a way to cope with it...
Various anti-debugging techniques and nasty runtime code obfuscation made this
journey somewhat challenging.
Parts of SafeDisc 2.x analyze the API code of the following system libraries:
kernel32.dll (wine builtin)
user32.dll (wine builtin)
gdi32.dll (wine builtin)
cdasdtst.dll (developer backdoor?)
The latter one is probably a "developer backdoor", used to verify their
code/algorithms (not needed to be present).
For each of these libraries all named exports are taken into account.
A number of API entry opcode sequences are read and used for statistical
analysis (number depends on type of encountered opcodes).
>From what I've seen there is some kind of "behavioural probability" of each API
entry calculated, with typical opcode sequences having a "weighting".
Just think of advanced heuristic detection methods of antivirus scanners and
you get the idea ;-).
Anyway, wine's builtin libraries differ in their signatures from windows entry
code and to make things worse, wine's +relay/+snoop feature heavily interferes
with the analyzer results. :-(
First I made some experiments with additional (dummy) function exports, small
__asm__ wrappers with opcode sequences to see how the distribution of opcodes
influences the analyzer results.
The result was rather disappointing.
I needed a large number of exports to gain some results but not significantly
enough to get below the "bad" threshold.
Then I came across the magic "0" value. As soon as I used this value either as
first .byte on API entry or init value for data export, the entry scan was
short circuited.
This value seemed to have the highest influence of all code/data sequences
used.
I added quite a number of data exports - aliased to initialized "0" value -
safe enough to let even wine's +relay work (remember: relay code influences
analyzer).
If you look at the patch don't get mad ;-)
You will see a crapload of named "__wine_safedisc2" data exports/aliases added
to wine builtin kernel32, user32 and gdi32.
For the record: http://bugs.winehq.org/show_bug.cgi?id=9926 which talks about
"problematic" gdi32 data exports (pfnPalette stuff) in SafeDisc 3.x.
SafeDisc 2.x code triggers SEH upon exported function pointers too but this is
gracefully handled. No harm at all.
I wonder if this is really a problem in SafeDisc 3.x ...
I thought about other possible solutions but found no one easier to implement
to prove my findings without hurting wine too much :-)
Making wrappers of the whole kernel32, user32, gdi32 named exports API just to
please the entry analyzer is not an option to me.
Another way could be the relocation of export table upon module loading,
expanding it at runtime by adding the required number of "statistics fakers"
(data exports with zero init).
This requires modifying the ntdll loader .. though i'm not sure if this
approach breaks other applications/braindamaged PE protection stuff which
expect certain conditions to be met (tables present at specific sections/memory
areas).
------------------------------
(2)
Well, take it as proof of concept. Play with it.
I tested my patch with a few SafeDisc 2.x games I have original media.
No cracks/no-cd patches were used.
Only official game patches were used.
Battlefield 1924 (1.6x) - SafeDisc 2.6/2.8
Road To Rome (BF1942 expansion) - SafeDisc 2.8
Battlefield Vietnam - SafeDisc 2.9
All of these work fine for me with the patch applied.
Please test this patch on many SafeDisc 2.x games as possible and report your
results (works or works not).
Make sure you have original media mounted and drive/data is visible within
wine.
If it fails for first time, the media might not ready yet, try again then (I
experienced this sometimes).
Use this link to verify what SafeDisc Version is used:
http://www.120search.net/ (alcohol software copy protection database)
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9798
Summary: bioshock demo needs glsl enabled
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-directx-d3d
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Created an attachment (id=8240)
--> (http://bugs.winehq.org/attachment.cgi?id=8240)
crash log with glsl disabled
Hello,
Bioshock demo crashes if glsl is not enabled.
Attached are relevant traces made with:
WINEDEBUG=+seh,+tid,+d3d,+d3d_shader wine ./Bioshock.exe -dx9
Using following registry settings enables bioshock demo to run:
--- snip ---
HKEY_CURRENT_USER/Software/Wine/Direct3D
UseGLSL = "enabled"
--- snip ---
Optional: OffscreenRenderingMode = "fbo"
==================
Addendum:
wine --version
wine-0.9.45-406-g2ba3247
Currently uses secuROM hack (http://bugs.winehq.org/attachment.cgi?id=8235
) to run, see http://bugs.winehq.org/show_bug.cgi?id=7065
Be sure to include "-dx9" command line to work around directx 10 issue.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10225
Summary: SafeDisc 2.x triggers async device ioctl status code
propagation bug in wine server
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: wine-kernel
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Created an attachment (id=8843)
--> (http://bugs.winehq.org/attachment.cgi?id=8843)
relevant trace which shows ioctl status code propagation bug
Hello,
while testing my proof-of-concept patch which makes SafeDisc v2 (yuck!) finally
work, I stumbled across a nasty ioctl status code propagation (completion) bug
in wine server.
Wasted several hours on it .. I was suspecting SD issue whole time, but its a
wine server bug :(
Attached is relevant trace (WINEDEBUG=+seh,+tid,+relay,+ntoskrnl,+server wine
./BfVietnam.exe)
Before the bug is triggered, the SafeDisc security driver makes several device
ioctl requests which return 0xC0000001 (unsuccessful) on purpose, e.g. reading
debug Drx registers with index that does not exist.
This is intended to fool reversers :-)
The next operation - checking IDT entries should succeed - but does not (as
seen from calling client).
The kernel driver completes the operation successfully and returns
irp.IoStatus.u.Status == 0 with xxxx bytes in output buffer.
I verified it several times by debugging the kernel driver.
Upon driver ioctl call return, get_next_device_request() is triggered again in
ntoskrnl event loop which sets the return data (and status code) ->
set_ioctl_result().
This queues an APC, waking up the client (alertable state).
The client process device ioctl completes with 0 (FALSE) which is wrong.
Further debugging showed that ioctl_completion APC (dlls/ntdll/file.c) returns
the errornous status code in get_ioctl_result() when woken up by server.
This error is then propagated in server_ioctl_file() to result in wrong
NtDeviceIoControlFile() return code.
What puzzled me is that "ioctl->status" is correctly set by set_ioctl_result()
(=0) but get_ioctl_result() - called within client context - yields the
previous error code (0xC0000001 of failed request).
This is either a problem of global vs. thread local error status (global_error
vs. current->error/thread) or the ioctl call data is the wrong one.
The following patch works for me, letting SD 2.x continue - though i'm not sure
if it's right:
--- snip ---
diff --git a/server/device.c b/server/device.c
index 46b2796..8fe8f7c 100644
--- a/server/device.c
+++ b/server/device.c
@@ -528,7 +528,7 @@ DECL_HANDLER(get_ioctl_result)
ioctl->out_data = NULL;
}
}
- set_error( ioctl->status );
+
list_remove( &ioctl->dev_entry );
release_object( ioctl ); /* no longer on the device queue */
}
--- snip ---
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10293
Summary: sequentially running games/apps with different SafeDisc
versions fails
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: wine-kernel
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Created an attachment (id=8945)
--> (http://bugs.winehq.org/attachment.cgi?id=8945)
Patch which fixes various isses regarding kmode driver unload/reload
Hello,
currently wine's kernel mode driver cleanup/unloading facility has several
issues when it comes to applications/games that unload and reload different
driver versions on the fly.
Example: run multiple SafeDisc 2.x, 3.x and 4.x games sequentially.
Symptoms: game either hangs/crashes/exits silently
Usually the SD security driver is placed in
"c:\windows\system32\drivers\secdrv.sys"
If a SafeDisc protected program encounters a driver version that is
incompatible it does the following:
- stop the current security service (should unload the driver)
- unpack own security driver from resources to temp storage and move the binary
to "c:\windows\system32\drivers\secdrv.sys", overwriting the previous
- restart the service (loads the new driver)
This currently fails for various reasons:
(1)
The driver binary is loaded using LoadLibrary() -> the matching FreeLibrary()
is missing on service stop.
This leads to sharing violation when the driver binary going to be replaced
(CopyFile fails).
(2)
No driver unload routine called. Very problematic.
Various objects (symlinks) created by driver entry are not freed.
When the driver is reloaded the init routine usually fails with "object
exists".
(3)
Driver state objects (driver_obj, driver_extension) have undefined state due to
static storage.
Raises all sorts of problems because the driver entry routine does not init all
fields.
---------
Attached is a patch which fixes these problems, allowing to sequentially run
programs with different SafeDisc Versions.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10451
Summary: Various AutoDesk 2008 product installers fail due to
unimplemented msi.MsiEnumComponentCostsW
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-msi
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Created an attachment (id=9156)
--> (http://bugs.winehq.org/attachment.cgi?id=9156)
stub impl of msi.MsiEnumComponentCostsW to keep AutoDesk 2008 installers happy
Hello,
various AutoDesk 2008 product installers fail due to unimplemented
msi.MsiEnumComponentCostsW API (mentioned in bug 9809).
--- snip ---
wine: Call from 0x7b841460 to unimplemented function
msi.dll.MsiEnumComponentCostsW, aborting
wine: Unimplemented function msi.dll.MsiEnumComponentCostsW called at address
0x7b841460 (thread 000e), starting debugger...
Unhandled exception: unimplemented function msi.dll.MsiEnumComponentCostsW
called in 32-bit code (0x7b8414d8).
--- snip ---
Attached patch makes installer happy.
Though that API (A/W) should be fleshed out some day ... this is left as
exercise for msi maintainers :-)
If you test this on AutoDesk 2008 installers, you need my shell32/shlfileop
patch from bug 9809 too.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=11789
Summary: Recent Fls API additions break many installers/apps
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: ntdll
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
after upgrading to recent GIT (wine-0.9.56-264-g848383a) it seems the recent
Fls API additions broke almost every installer i'm working on ;-(
http://source.winehq.org/git/wine.git/?a=commit;h=6d6e9a42b13c827d1cc795c3b…http://source.winehq.org/git/wine.git/?a=commit;h=b2ad268a8b7d7ac65029bbdd7…
I won't question if there was a specific need to introduce this ...
Reason of crash in FlsAlloc() is simple.
Different TEB definition in <thread.h> vs. <winternl.h> leads to incorrect TEB
allocation size (ntdll -> thread.h) vs. usage (fiber/Fls -> winternl.h)
Solution: use winternl.h TEB definition to ensure correct TEB allocation size
in dlls/ntdll/thread.c
Either change include order of both (needs <stdarg.h>) .. or sync both .. or
better get rid of the thread.h one to avoid such recurring problem.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=14499
Summary: ImageDirectoryEntryToDataEx: section header param [out,
optional], needs to be zeroed before RtlImageRvaToVa
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: dbghelp
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
a quickie, as title says.
Section header param passed to ImageDirectoryEntryToDataEx is [out, optional].
Crashes RtlImageRvaToVa if caller doesn't initialize the out param to zero
(stack var).
--- snip ---
..
0020:Call
dbghelp.ImageDirectoryEntryToDataEx(00340000,00000000,00000006,0032cc34,0032cc38)
ret=004048ec
0020:Call ntdll.RtlImageNtHeader(00340000) ret=6076ce7b
0020:Ret ntdll.RtlImageNtHeader() retval=003400e8 ret=6076ce7b
0020:Call ntdll.RtlImageRvaToVa(003400e8,00340000,00001270,0032cc38)
ret=6076ceeb
0020:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7bc4337a
--- snip ---
Fix: unconditionally "if (section) *section = NULL" on
ImageDirectoryEntryToDataEx entry (like size).
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=14568
Summary: Silence FIXME from CoGetContextToken stub to prevent
flooding of trace output when COM+ context is queried
from .NET runtime
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: ole32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
ole32.CoGetContextToken being currently a stub prints out large amounts of
FIXME's when .NET runtime queries COM+ context for run/debugged .NET
applications.
--- snip ---
..
fixme:ole:CoGetContextToken stub
fixme:ole:CoGetContextToken stub
fixme:ole:CoGetContextToken stub
fixme:ole:CoGetContextToken stub
fixme:ole:CoGetContextToken stub
..
<repeat this gazillion times>
--- snip ---
Please use a static or remove the FIXME.
It's really annoying and makes console tracing/debugging of .NET apps really
messy.
And no, WINEDEBUG=-ole is *not* an option, it actually hides other bugs.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16544
Summary: winmm: mixerOpen(): when CALLBACK_WINDOW flag given,
NULL Callback is also valid
Product: Wine
Version: 1.1.10
Platform: PC-x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winmm&mci
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
while revisiting a Battlefield 2 issue I came across another one...
BF2 voice setup (C:\Program Files\EA GAMES\Battlefield 2\BF2VoiceSetup.exe)
crashes when "Save Settings" button is clicked.
This happens from BF2 sub-installer (causing no harm) or when the voice setup
app is run stand alone.
--- snip ---
..
wine: Unhandled page fault on read access to 0x0000002c at address 0x408661
(thread 0044), starting debugger...
Unhandled exception: page fault on read access to 0x0000002c in 32-bit code
(0x00408661).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:00408661 ESP:0033dadc EBP:0033dbc0 EFLAGS:00010216( - 00 -RIAP1)
EAX:00000000 EBX:00000111 ECX:00000000 EDX:00000002
ESI:0033dadc EDI:0033dbc0
Stack dump:
0x0033dadc: 00000001 0033f60c 00000111 cccccccc
0x0033daec: cccccccc cccccccc cccccccc cccccccc
0x0033dafc: cccccccc cccccccc cccccccc cccccccc
0x0033db0c: cccccccc cccccccc cccccccc cccccccc
0x0033db1c: cccccccc cccccccc cccccccc cccccccc
0x0033db2c: cccccccc cccccccc cccccccc cccccccc
Backtrace:
=>0 0x00408661 in bf2voicesetup (+0x8661) (0x0033dbc0)
1 0x00403978 in bf2voicesetup (+0x3978) (0x0033dd8c)
2 0x7c171915 in mfc71 (+0x31915) (0x0033ddbc)
3 0x7c14db36 in mfc71 (+0xdb36) (0x0033dde0)
4 0x7c175cd8 in mfc71 (+0x35cd8) (0x0033de30)
5 0x7c175cf2 in mfc71 (+0x35cf2) (0x0033dec4)
..
--- snip ---
The crash location is only indirectly related to the problem, hence this was a
bit tricky to debug to the real cause.
The real problem seems to be a Wine's winmm.mixerOpen() handling fdwOpen flags
with CALLBACK_WINDOW when dwCallback is NULL.
Consider the following (WINEDEBUG=+winmm):
--- snip ---
0023:trace:winmm:DllMain 0x60380000 0x1 0x1
0023:trace:winmm:MMDRV_Init ()
..
0023:trace:winmm:MIXER_Open (0x425f0c, 0, 00000000, 00000000, 00010000)
..
--- snip ---
mixerOpen() with CALLBACK_WINDOW flags and NULL dwCallback results in
MMSYSERR_INVALPARAM.
Corresponding Wine code:
--- snip dlls/winmm/winmm.c:MIXER_Open ---
UINT MIXER_Open(LPHMIXER lphMix, UINT uDeviceID, DWORD_PTR dwCallback,
DWORD_PTR dwInstance, DWORD fdwOpen, BOOL bFrom32)
{
...
switch (fdwOpen & CALLBACK_TYPEMASK) {
..
case CALLBACK_WINDOW:
mod.dwInstance = dwCallback;
if (!IsWindow((HWND)dwCallback))
return MMSYSERR_INVALPARAM;
break;
}
..
}
--- snip dlls/winmm/winmm.c:MIXER_Open ---
MSDN: http://msdn.microsoft.com/en-us/library/ms712134.aspx
It says: "The dwCallback parameter is assumed to be a window handle (HWND)."
Unfortunately the app expects MMSYSERR_NOERROR but not a failure (bad app error
handling anyway).
Hence crucial data structures are not getting setup properly (C++
instances/member data), leading to NULL ptr dereference at much later time.
A small conformance test case (fdwOpen=CALLBACK_WINDOW, dwCallback=NULL) should
reveal this MSDN documentation insufficiency.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16598
Summary: winuser.rh misses some standard control ids (dialog
button, ...) resulting in wrc failure with windows.h
include only
Product: Wine
Version: 1.1.10
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
while doing some occasional end user support on #winehq (*yuck*), one user
complained about wrc not compiling his .rc file.
Visual C++ and mingw toolchains compiled it in Windows without problems but
Wine's wrc didn't like it.
--- snip ---
...
resource.rc:114:31: Error: syntax error
--- snip ---
He sent me a link to the .rc file to have a look at.
Relevant parts:
Resource.rc:
--- snip ---
// Microsoft Visual C++ generated resource script.
//
#include "resource.h"
#define APSTUDIO_READONLY_SYMBOLS
/////////////////////////////////////////////////////////////////////////////
//
// Generated from the TEXTINCLUDE 2 resource.
//
#include <windows.h>
/////////////////////////////////////////////////////////////////////////////
#undef APSTUDIO_READONLY_SYMBOLS
...
/////////////////////////////////////////////////////////////////////////////
//
// Menu
//
IDR_MENU MENU
BEGIN
...
END
/////////////////////////////////////////////////////////////////////////////
//
// Dialog
//
IDD_MEMTRANSFER DIALOGEX 100, 100, 174, 90
STYLE DS_SETFONT | DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION |
WS_SYSMENU
CAPTION "Memory Transfer"
FONT 8, "Courier New", 0, 0, 0x0
BEGIN
DEFPUSHBUTTON "&OK",IDOK,42,72,40,14
...
--- snip ---
Resource.h:
--- snip ---
//{{NO_DEPENDENCIES}}
// Microsoft Visual C++ generated include file.
// Used by resource.rc
//
#define IDR_MENU 100
#define IDI_ICON 101
#define IDB_BITMAP 102
#define IDR_MAIN_ACCEL 103
#define IDD_MEMTRANSFER 104
...
--- snip ---
The resource include chain is as follows:
resource.h
windows.h (due to RC_INVOKED defined by wrc) -> winresrc.h -> winuser.rh and
commctrl.rh
The problem is that winuser.rh defines only a subset of winuser.h control ids
This breaks resource scripts which for example reference standard dialog button
IDs.
Telling the user to explicitly include <winuser.h> solved his problems.
You might want to extend winuser.rh a bit to include often used standard
control ids (ex: dialog button).
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=13399
Summary: Appdb doesn't remember logins
Product: WineHQ Apps Database
Version: unspecified
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: appdb-unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: tehblunderbuss(a)gmail.com
The appdb doesn't remember logins, like how the bugzilla or wiki do.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=12939
Summary: >=wine-0.9.59: Selection using control key and mouse
button does not work.
Product: WineHQ Bugzilla
Version: unspecified
Platform: PC
URL: http://www.foobar2000.org
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: bugzilla-unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: h.judt(a)gmx.at
In Foobar2000, <Control>-<Mouse1> should select or deselect a single entry in
the playlist. Instead, it just selects a new entry and deselects all others as
if the control key has not been pressed.
This worked in <wine-0.9.59 but does not in >=wine-0.9.59 (last version tested
was 0.9.61).
Similar problem with <Shift>-<Mouse1> existed in =wine-0.9.59, but was solved
in >=0.9.60 and works fine now.
Occurs with: Foobar2000-0.9.4.4, Exact Audio Copy-0.99prebeta4, file selector
dialogs, but might effect other software / versions / dialogs as well.
When I launch Foobar2000 and try to add files, I get the following messages on
the terminal, maybe this is of some help:
fixme:menu:TrackPopupMenuEx not fully implemented
fixme:commdlg:GetFileName95 Flags 0x00800000 not yet implemented
fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000011
fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000041
fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000010
fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000011
fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000011
fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000041
fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000010
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=21777
Summary: CreateMutexExA(): use heap for A to W conversion to
work around transbase db engine app bug (affects
multiple apps, TecDoc CATALOG ...)
Product: Wine
Version: 1.1.39
Platform: x86
URL: http://www.tecdoc.de
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: kernel32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
at the end of TecDoc CATALOG 1/2010 DVD install a crash dialog is displayed
while starting a service (the msi part of install is finished anyway).
The database engine service has auto-start type set hence on every program
start (wine notepad) the infamous crash dialog is displayed.
This turns out to be an app bug but due to differences in Wine vs. Windows API
design/usage this bug has no consequences in Windows and goes on unnoticed.
Unfortunately the part of software that crashes comes from another software
supplier "Transaction Software" (http://www1.transaction.de/transaction/).
Many automotive spare parts catalogue software (BMW, VW, Audi, GM, Fiat ...)
internally use the Transbase SQL database engine for years.
In case of Wine/Linux this means many broken apps/versions in the wild due to
this bug and even if the original software supplier fixes the bug, it will take
years until spare parts catalogue software vendors using the engine to pick up
and release new versions of their own products.
Despite being an app bug I suggest to modify Wine to work around this developer
stupidity.
Here it goes, first the crash itself:
--- snip ---
wine: Unhandled page fault on read access to 0x012f0000 at address 0x681ee546
(thread 001d), starting debugger...
Unhandled exception: page fault on read access to 0x012f0000 in 32-bit code
(0x681ee546).
...
Threads:
process tid prio (all id:s are in hex)
...
00000019 (D) C:\TECDOC_CD\1_2010\db\tbmux32.exe
0000001d 0 <==
0000001b 0
0000001a 0
...
Backtrace:
=>0 0x681ee546 (0x012eddd4)
1 0x7bc79ac0 NtCreateMutant+0xae(MutantHandle=0x12eded4, access=0x1f0001,
attr=0x12edeb4, InitialOwner=0) [/opt/wine/wine-git/dlls/ntdll/sync.c:429] in
ntdll (0x012ede94)
2 0x7b869dc8 CreateMutexExW+0xb2(sa=0x12ee16c, name="Global\TBSEM ( TECDOC_C
) = (Key=32769, Ind=0)", flags=0, access=0x1f0001)
[/opt/wine/wine-git/dlls/kernel32/sync.c:653] in kernel32 (0x012edee4)
3 0x7b869d0c CreateMutexExA+0xb6(sa=0x12ee16c, name="Global\TBSEM ( TECDOC_C
) = (Key=32769, Ind=0)", flags=0, access=0x1f0001)
[/opt/wine/wine-git/dlls/kernel32/sync.c:626] in kernel32 (0x012ee124)
4 0x7b869c08 CreateMutexA+0x3a(sa=0x12ee16c, owner=0, name="Global\TBSEM (
TECDOC_C ) = (Key=32769, Ind=0)") [/opt/wine/wine-git/dlls/kernel32/sync.c:599]
in kernel32 (0x012ee144)
5 0x0041a2a3 in tbmux32 (+0x1a2a3) (0x74fd9c13)
6 0x458d28ec (0x83e58955)
--- snip ---
Starting the whole thing (db service) with +relay exhibits a different
behaviour: the service doesn't crash but it doesn't really work, indicating a
stack usage problem.
Have a close look at security descriptor dump, DACL part:
--- snip ---
001e:Call advapi32.InitializeSecurityDescriptor(012ee2bc,00000001) ret=00419b06
001e:Ret advapi32.InitializeSecurityDescriptor() retval=00000001 ret=00419b06
001e:Call advapi32.InitializeAcl(012ede8c,00000400,00000002) ret=00419b28
001e:Ret advapi32.InitializeAcl() retval=00000001 ret=00419b28
001e:Call advapi32.InitializeSid(012eda8c,012eda84,00000001) ret=00419b47
001e:Ret advapi32.InitializeSid() retval=00000001 ret=00419b47
001e:Call advapi32.GetSidSubAuthority(012eda8c,00000000) ret=00419b60
001e:Ret advapi32.GetSidSubAuthority() retval=012eda94 ret=00419b60
001e:Call advapi32.AddAccessAllowedAce(012ede8c,00000002,10000000,012eda8c)
ret=00419b7c
001e:Ret advapi32.AddAccessAllowedAce() retval=00000001 ret=00419b7c
001e:Call
advapi32.SetSecurityDescriptorDacl(012ee2bc,00000001,012ede8c,00000000)
ret=00419b9e
001e:Ret advapi32.SetSecurityDescriptorDacl() retval=00000001 ret=00419b9e
001e:Call KERNEL32.CreateMutexA(012ee2b0,00000000,012ee2d0 "Global\\TBSEM (
TECDOC_C ) = (Key=808607544, Ind=0)") ret=0041a2a3
001e: create_mutex( access=001f0001, attributes=00000080, owned=0,
objattr={rootdir=0018,sd={control=00000004,owner=<not present>,group=<not
present>,sacl={},dacl={{AceType=unknown<156>,AceFlags=e2},{AceType=unknown<46>,AceFlags=1}}},name=L"Global\\TBSEM
( TECDOC_C ) = (Key=808607544, Ind=0)"} )
001e: create_mutex() = INVALID_SECURITY_DESCR { handle=0000 }
001e:Ret KERNEL32.CreateMutexA() retval=00000000 ret=0041a2a3
--- snip ---
Pretty much messed up.
To keep the story short, I translated debugger disassembly snippets and
annotated stack dumps into a snippet of C code so you won't get annoyed with
too much detail ;-)
This is most likely what the app does (might not be 100% accurate, just to
illustrate the problem):
--- stupid app code start ---
static int prepare_sd( SECURITY_ATTRIBUTES *sa)
{
SID_IDENTIFIER_AUTHORITY sia_world = SECURITY_WORLD_SID_AUTHORITY;
BYTE user_sid[0x400];
BYTE acl_buffer[0x400];
int res = InitializeSecurityDescriptor( sa->lpSecurityDescriptor,
SECURITY_DESCRIPTOR_REVISION);
if( !retval)
return res;
res = InitializeAcl( (PACL) acl_buffer, sizeof(acl_buffer), ACL_REVISION);
if( !retval)
return res;
res = InitializeSid( (PSID) user_sid, &sia_world, 1);
if( !retval)
return res;
*GetSidSubAuthority( (PSID) user_sid, 0) = SECURITY_WORLD_RID;
res = AddAccessAllowedAce( (PACL) acl_buffer, ACL_REVISION, 0x10000000,
(PSID) user_sid);
if( !retval)
return res;
return SetSecurityDescriptorDacl( sa->lpSecurityDescriptor, TRUE,
(PACL)acl_buffer, FALSE);
}
static int open_app_mutex( ...)
{
SECURITY_DESCRIPTOR sd;
SECURITY_ATTRIBUTES sa = {0};
char name[0x80];
wsprintfA( name, "xxx", ...);
sa.nLength= sizeof(SECURITY_ATTRIBUTES);
sa.lpSecurityDescriptor = &sd;
sa.bInheritHandle = FALSE;
prepare_sd( &sa);
CreateMutexA( &sa, FALSE, name);
...
}
--- stupid app code end ---
You can probably spot the biggest mistake of all pretty soon: some "genius"
decided to put everything on stack in prepare_sd().
Upon return of prepare_sd() helper function, the stack locals used within
prepare_sd() are still *intact*
When the app calls CreateMutexA(), the call sequence is as follows:
CreateMutexA -> CreateMutexExA -> CreateMutexExW -> NtCreateMutant
--- snip dlls/kernel32/sync.c ---
HANDLE WINAPI CreateMutexA( SECURITY_ATTRIBUTES *sa, BOOL owner, LPCSTR name )
{
return CreateMutexExA( sa, name, owner ? CREATE_MUTEX_INITIAL_OWNER : 0,
MUTEX_ALL_ACCESS );
}
...
HANDLE WINAPI CreateMutexExA( SECURITY_ATTRIBUTES *sa, LPCSTR name, DWORD
flags, DWORD access )
{
WCHAR buffer[MAX_PATH];
if (!name) return CreateMutexExW( sa, NULL, flags, access );
if (!MultiByteToWideChar( CP_ACP, 0, name, -1, buffer, MAX_PATH ))
{
SetLastError( ERROR_FILENAME_EXCED_RANGE );
return 0;
}
return CreateMutexExW( sa, buffer, flags, access );
}
--- snip dlls/kernel32/sync.c ---
The problem is buried within CreateMutexExA(): the A to W conversion uses a
stack based buffer of MAX_PATH len.
This eats stack, partly overwriting the ACL buffer (DACL) from previous
prepare_sd() which used to be a stack local too.
The reason that this doesn't happen on Windows is most likely conversions are
heap based or the call path to kernel mode is very short, not consuming that
much stack as Wine does.
I verified with a patch to use heap based buffer in CreateMutexExA() for A to W
conversion (similar what's being done in CreateMailslotA()) and it lets the app
succeed despite that nasty stack bug.
I'll leave it to Alexandre to judge this (change or leave Wine as it is).
If you decide for WONTFIX (that app bug would really deserve such treatment), I
will attach a patch to give users a chance work around various broken transbase
versions.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=24213
Summary: WMI: provide "WMIC" stub executable to silence various
"file not found" messages (Java SE JRE/JDK installers)
Product: Wine
Version: 1.3.1
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: wmi&wbemprox
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
when installing Java SE JRE/JDK, the installer calls the WMIC executable (using
"cmd"), cluttering console with messages:
--- snip ---
wine: cannot find L"C:\\windows\\system32\\WMIC.exe"
--- snip ---
This is a tool to access Windows Management Instrumentation (WMI) from the
command line, part of WMI core.
See: http://msdn.microsoft.com/en-us/library/aa394531.aspx
Trace log:
--- snip ---
0047:Call KERNEL32.CreateProcessA(00000000,005dead0 "cmd /C WMIC computersystem
get
model",00000000,00000000,00000001,08000400,00000000,00000000,0074e3f8,0074e43c)
ret=6d337ea3
...
0047:Ret KERNEL32.CreateProcessA() retval=00000001 ret=6d337ea3
...
0023:Call KERNEL32.CreateProcessW(00000000,0013a9c8 L"WMIC computersystem get
model",00000000,00000000,00000001,00000000,00000000,00000000,0033eff0,0033f034)
ret=68198ea3
...
wine: cannot find L"C:\\windows\\system32\\WMIC.exe"
0023:Ret KERNEL32.CreateProcessW() retval=00000000 ret=68198ea3
...
0047:Call KERNEL32.CreateProcessA(00000000,005ef958 "cmd /C WMIC computersystem
get
manufacturer",00000000,00000000,00000001,08000400,00000000,00000000,0074e3e8,0074e42c)
ret=6d337ea3
...
0047:Call KERNEL32.CreateProcessA(00000000,005ef958 "cmd /C WMIC bios get
serialnumber",00000000,00000000,00000001,08000400,00000000,00000000,0074e3e8,0074e42c)
ret=6d337ea3
...
0047:Call KERNEL32.CreateProcessA(00000000,005ef958 "cmd /C WMIC cpu get
manufacturer",00000000,00000000,00000001,08000400,00000000,00000000,0074e3f8,0074e43c)
ret=6d337ea3
...
--- snip ---
Would be fine if Wine could provide a stub executable to silence this until
real work on WMI starts one day ... (like Wine's "lodctr" for .NET stuff)
Ideally the WMIC stub should print the command line passed to it using own
debug channel ;-)
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27400
Summary: SecuROM 4.x/5.x helper driver needs
ntoskrnl.exe.IoSetThreadHardErrorMode stub
Product: Wine
Version: 1.3.21
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ntoskrnl
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
the driver is part of SecuROM 4.x/5.x and dynamically extracted and loaded if
"\Device\CdRom0" is present (cdrom0 -> /dev/cdrom via manually created symlink
in dosdevices).
The driver isn't particularly useful as of now but it shouldn't crash.
--- snip ---
...
0021:Call KERNEL32.CreateFileA(0032ce0c
"C:\\users\\focht\\Temp\\pfsvgae.sys",40000000,00000000,00000000,00000002,00000000,00000000)
ret=00486114
0021:Ret KERNEL32.CreateFileA() retval=00000080 ret=00486114
...
0021:Call advapi32.CreateServiceA(00161bc8,0032d00c "pfsvgae",0032d00c
"pfsvgae",000f01ff,00000001,00000003,00000001,0032ce0c
"C:\\users\\focht\\Temp\\pfsvgae.sys",00000000,00000000,00000000,00000000,00000000)
ret=00487aae
...
fixme:ntoskrnl:IoGetDeviceObjectPointer stub: L"\\Device\\CdRom0" 0 0x53e20c
0x53e1e8
fixme:ntoskrnl:IoRegisterDriverReinitialization stub: 0x787a54a0 0x541a6f (nil)
fixme:ntoskrnl:IoGetDeviceObjectPointer stub: L"\\Device\\LanmanRedirector" 1
0x53e21c 0x53e218
fixme:ntoskrnl:IoGetDeviceObjectPointer stub: L"\\Device\\NetWareRedirector" 1
0x53e21c 0x53e218
wine: Call from 0x7b838b9b to unimplemented function
ntoskrnl.exe.IoSetThreadHardErrorMode, aborting
wine: Unimplemented function ntoskrnl.exe.IoSetThreadHardErrorMode called at
address 0x7b838b9b (thread 0028), starting debugger...
wine: Call from 0x7b838b9b to unimplemented function
ntoskrnl.exe.IoSetThreadHardErrorMode, aborting
--- snip ---
MSDN: http://msdn.microsoft.com/en-us/library/ff550342.aspx
The driver uses the IoSetThreadHardErrorMode API as follows:
--- snip pseudo code ---
old_harderror = IoSetThreadHardErrorMode( FALSE);
// device: L"\\DosDevices\\C:\\" ... L"\\DosDevices\\D:\\" ...
ZwCreateFile( ... device ... )
IoSetThreadHardErrorMode( old_harderror)
--- snip pseudo code ---
This is to prevent a message box like "There is no disk in the drive. Please
insert a disk into drive x" or "Windows cannot access the specified device,
path or file." from being shown when the device link is not present or no cdrom
is inserted.
The driver iterates through all possible drive letters regardless if applicable
or not.
The return value doesn't really matter for now.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27550
Summary: SafeDisc 4.x: first opcode byte of
kernel32.DebugBreak() API entry must not be "int 3"
(0xCC) (Rainbow Six: Vegas 2 fails on startup)
Product: Wine
Version: 1.3.22
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: kernel32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
"Rainbow Six: Vegas 2" complains about a debugger being present.
The game shows a message box on startup:
"A debugger has been detected"
"Unload the debugger and try again"
--- snip ---
=[ ProtectionID v0.6.4.0 JULY]=-
(c) 2003-2010 CDKiLLER & TippeX
Build 07/08/10-17:57:05
Ready...
Scanning -> Z:\home\focht\.wine\drive_c\Program Files\Ubisoft\Tom Clancy's
Rainbow Six Vegas 2\Binaries\R6Vegas2_Game.exe
File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 30277768 (01CE0088h)
Byte(s)
-> File Appears to be Digitally Signed @ Offset 01CDEE00h, size : 01288h /
04744 byte(s)
-> File has 1449472 (0161E00h) bytes of appended data starting at offset
01B7D000h
[File Heuristics] -> Flag : 00000000000000000100000000000111 (0x00004007)
[!] Safedisc v4.85.000 detected !
[i] Appended data contents....
[.] o: 0x01B7D028 / t: <0xA8726B03> <0xEF01996C> <0x00000001> / s: 00302963
byte(s) -> ~deaa13.tmp
[.] o: 0x01BC6FC2 / t: <0xA8726B03> <0xEF01996C> <0x0000044C> / s: 00015887
byte(s) -> clcd32.dll
[.] o: 0x01BCADF8 / t: <0xA8726B03> <0xEF01996C> <0x0000044C> / s: 00004122
byte(s) -> clcd16.dll
[.] o: 0x01BCBE36 / t: <0xA8726B03> <0xEF01996C> <0x0000044D> / s: 00037971
byte(s) -> mcp.dll
[.] o: 0x01BD52B2 / t: <0xA8726B03> <0xEF01996C> <0x0000000B> / s: 00005446
byte(s) -> SecDrv04.VxD
[.] o: 0x01BD681D / t: <0xA8726B03> <0xEF01996C> <0x00000000> / s: 00072192
byte(s) -> ~e5.0001
[.] o: 0x01BE8244 / t: <0xA8726B03> <0xEF01996C> <0x00000000> / s: 00045056
byte(s) -> PfdRun.pfd
[.] o: 0x01BF326C / t: <0xA8726B03> <0xEF01996C> <0x00000000> / s: 00965148
byte(s) -> ~df394b.tmp
[CompilerDetect] -> Visual C++ 8.0 (Visual Studio 2005)
- Scan Took : 1.569 Second(s)
--- snip ---
I debugged the protection through various anti-debugging checks and found out a
specific check failed.
SafeDisc 4.x checks all kernel32 exports and specifically looks for
soft-breakpoints (0xcc) on API entries.
This fails now for kernel32.DebugBreak() because AJ used an inline asm int 3
(0xcc) to fix bug 24157
The protection treats this as "malicious" soft breakpoint and flags this entry
as "bad".
bug 24157 ->
http://source.winehq.org/git/wine.git/commitdiff/5f06809ab3339e2001de57f18b…
- technically a regression.
Fortunately SafeDisc only checks the first opcode byte so one could prepend a
simple "HOTPATCH" instruction to work around that.
Though I'm not sure if this is a "safe" long term solution (in this case it's
sufficient).
Another way could be forwarding kernel32.DebugBreak to ntdll.DbgBreakPoint
I only tested both methods, they work.
Though the copy protection later fails for DVD media validation but this is
another bug.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=13958
Summary: Services: handle null display names properly when
populating SCM db entries
Product: Wine
Version: 1.0-rc5
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: programs
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
there is a bug in services code when one or more services have no display name
set (null).
If CreateServiceW() is called, it checks for existing services using
scmdatabase_find_service_by_displayname().
Unfortunately this internal helper doesn't handle the "null" service name
properly while iterating, resulting in exception and messy side effects
(although mapped to rpc exception it isn't propagated properly).
Following is service db dump with such cases:
--- snip ---
000d:trace:service:scmdatabase_load_services Loading service L"BITS"
000d:trace:service:load_service_config Image path = L"svchost.exe -k
netsvcs"
000d:trace:service:load_service_config Group = (null)
000d:trace:service:load_service_config Service account name = L"LocalSystem"
000d:trace:service:load_service_config Display name = L"BITS"
000d:trace:service:load_service_config Service dependencies : (none)
000d:trace:service:load_service_config Group dependencies : (none)
000d:trace:service:scmdatabase_load_services Loading service L"MountMgr"
000d:trace:service:load_service_config Image path =
L"C:\\windows\\system32\\drivers\\mountmgr.sys"
000d:trace:service:load_service_config Group = (null)
000d:trace:service:load_service_config Service account name = L"LocalSystem"
000d:trace:service:load_service_config Display name = L"Mount Manager"
000d:trace:service:load_service_config Service dependencies : (none)
000d:trace:service:load_service_config Group dependencies : (none)
000d:trace:service:scmdatabase_load_services Loading service L"MSIServer"
000d:trace:service:load_service_config Image path =
L"C:\\windows\\system32\\msiexec.exe /V"
000d:trace:service:load_service_config Group = (null)
000d:trace:service:load_service_config Service account name = L"LocalSystem"
000d:trace:service:load_service_config Display name = L"MSIServer"
000d:trace:service:load_service_config Service dependencies : (none)
000d:trace:service:load_service_config Group dependencies : (none)
000d:trace:service:scmdatabase_load_services Loading service L"PnkBstrA"
000d:trace:service:load_service_config Image path =
L"C:\\windows\\system32\\PnkBstrA.exe"
000d:trace:service:load_service_config Group = (null)
000d:trace:service:load_service_config Service account name = L"LocalSystem"
000d:trace:service:load_service_config Display name = L"PnkBstrA"
000d:trace:service:load_service_config Service dependencies : (none)
000d:trace:service:load_service_config Group dependencies : (none)
000d:trace:service:scmdatabase_load_services Loading service L"PnkBstrB"
000d:trace:service:load_service_config Image path =
L"C:\\windows\\system32\\PnkBstrB.exe"
000d:trace:service:load_service_config Group = (null)
000d:trace:service:load_service_config Service account name = L"LocalSystem"
000d:trace:service:load_service_config Display name = L"PnkBstrB"
000d:trace:service:load_service_config Service dependencies : (none)
000d:trace:service:load_service_config Group dependencies : (none)
000d:trace:service:scmdatabase_load_services Loading service L"PnkBstrK"
000d:trace:service:load_service_config Image path =
L"C:\\windows\\system32\\drivers\\PnkBstrK.sys"
000d:trace:service:load_service_config Group = (null)
000d:trace:service:load_service_config Service account name = L"LocalSystem"
000d:trace:service:load_service_config Display name = L"PnkBstrK"
000d:trace:service:load_service_config Service dependencies : (none)
000d:trace:service:load_service_config Group dependencies : (none)
000d:trace:service:scmdatabase_load_services Loading service L"PROCMON13"
000d:trace:service:load_service_config Image path =
L"\\??\\C:\\windows\\system32\\Drivers\\PROCMON13.SYS"
000d:trace:service:load_service_config Group = (null)
000d:trace:service:load_service_config Service account name = (null)
000d:trace:service:load_service_config Display name = (null)
000d:trace:service:load_service_config Service dependencies : (none)
000d:trace:service:load_service_config Group dependencies : (none)
000d:trace:service:scmdatabase_load_services Loading service L"SecDrv"
000d:trace:service:load_service_config Image path =
L"C:\\windows\\system32\\drivers\\\\SECDRV.SYS"
000d:trace:service:load_service_config Group = (null)
000d:trace:service:load_service_config Service account name = L"LocalSystem"
000d:trace:service:load_service_config Display name = L"SecDrv"
000d:trace:service:load_service_config Service dependencies : (none)
000d:trace:service:load_service_config Group dependencies : (none)
000d:trace:service:scmdatabase_load_services Loading service L"Spooler"
000d:trace:service:load_service_config Image path =
L"C:\\windows\\system32\\spoolsv.exe"
000d:trace:service:load_service_config Group = L"SpoolerGroup"
000d:trace:service:load_service_config Service account name = L"LocalSystem"
000d:trace:service:load_service_config Display name = L"Print Spooler"
000d:trace:service:load_service_config Service dependencies : (none)
000d:trace:service:load_service_config Group dependencies : (none)
000d:trace:service:scmdatabase_load_services Loading service L"VxD"
000d:trace:service:load_service_config Image path = (null)
000d:trace:service:load_service_config Group = (null)
000d:trace:service:load_service_config Service account name = (null)
000d:trace:service:load_service_config Display name = (null)
000d:trace:service:load_service_config Service dependencies : (none)
000d:trace:service:load_service_config Group dependencies : (none)
--- snip ---
Quick fix:
--- snip ---
diff --git a/programs/services/services.c b/programs/services/services.c
index 806fbb6..d48c985 100644
--- a/programs/services/services.c
+++ b/programs/services/services.c
@@ -341,7 +341,7 @@ struct service_entry
*scmdatabase_find_service_by_displayname(struct scmdatabase
LIST_FOR_EACH_ENTRY(service, &db->services, struct service_entry, entry)
{
- if (strcmpiW(name, service->config.lpDisplayName) == 0)
+ if (service->config.lpDisplayName && strcmpiW(name,
service->config.lpDisplayName) == 0)
return service;
}
--- snip ---
Hopefully it's not too late for 1.0 ;-|
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18122
Summary: Add ability to force specific order of notes/howtos
Product: WineHQ Apps Database
Version: unspecified
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: appdb-unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
I would like to see the ability to force the order of NOTES/HOWTOS.
I experimented with deleting and re-adding notes or adding some number "prefix"
in headline to force ordering but they still appear in some random order.
This feature would improve readability as there are several appdb entries which
contain a large number of notes/howtos and the most important ones should be
displayed first.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=24584
Summary: Serif Draw SE installer fails
Product: Wine
Version: 1.3.3
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: msi
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: intialonso(a)yahoo.com
Running setup.exe shows:
wine setup.exe
fixme:storage:create_storagefile Storage share mode not implemented.
fixme:advapi:LookupAccountNameW (null) L"mendicante" (nil) 0x32ea54 (nil)
0x32ea58 0x32ea4c - stub
fixme:advapi:LookupAccountNameW (null) L"mendicante" 0x1cfc78 0x32ea54 0x1cfb38
0x32ea58 0x32ea4c - stub
fixme:msi:msi_unimplemented_action_stub MigrateFeatureStates -> 3 ignored
L"Upgrade" table values
err:msi:ITERATE_Actions Execution halted, action L"NotWelcomeDlg" returned 1602
And this message:
"this action is not supported, please use setup.exe"
Im using wine 1.3.3 on Ubuntu 10.10rc
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17076
Summary: Embedded .NET installer hangs in installation of
SnelStart
Product: Wine
Version: 1.1.13
Platform: PC-x86-64
URL: http://www.snelstart.nl/Proberen/Proberen.aspx
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: Paul.Vriens.Wine(a)gmail.com
(SnelStart is a Dutch Accounting Application)
I'm running up-to-date GIT.
When running 'wine SetupDemoSnelStart.exe' one sees that it downloads
dotnetfx.exe (http://www.installengine.com/cert05/dotnetfx/dotnetfx.exe). After
that there will be a 'InstallShield Wizard' window that keeps busy stating that
it's configuring the .NET framework.
'ps -ef' shows:
C:\windows\temp\{A4D5D16A-A0C9-4F8A-8929-F0B61C32EDEB}\dotnetfx.exe /q:a
/ver:v1.1.4322 /redistui:S /c:/q:a /c:install /q /coreui:1033
I have no idea what logs to attach so please advise.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.