http://bugs.winehq.org/show_bug.cgi?id=14218
Summary: OleLoadPictureEx is not fully implemented (ole32)
Product: Wine
Version: 1.1.0
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: ole
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: mehlers(a)adata.de
Created an attachment (id=14504)
--> (http://bugs.winehq.org/attachment.cgi?id=14504)
Wine Output for OleLoadPictureEx
The Main Window of our Software under Windows shows a Picture. If we use the
builtin-Version of ole32 the Picture is not displayed. It seems that
"OleLoadPictureEx" ist not fully implemented.
See attachment "output.txt" for more information.
adata Software GmbH
Michael Ehlers
--
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=22846
Summary: wine's internet explorer can't download firefox
Product: Wine
Version: 1.2-rc1
Platform: x86
URL: http://www.getfirefox.com
OS/Version: Linux
Status: NEW
Keywords: download
Severity: minor
Priority: P2
Component: mshtml
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: austinenglish(a)gmail.com
As everyone who's installed Windows (and isn't in the EU) knows, the main use
of Internet Explorer is to download firefox. Unfortunately, wine's IE can't
download firefox:
$ wine iexplore.exe http://www.getfirefox.com
Click download, choose windows, and...nothing. Relevant terminal output:
fixme:mshtml:nsChannel_IsNoStoreResponse (0x2a06a38)->(0x32ee7c)
fixme:mshtml:nsChannel_IsNoCacheResponse (0x2a06a38)->(0x32ee78)
fixme:mshtml:nsChannel_Cancel (0x2a06a38)->(804b0002)
fixme:mshtml:nsHttpChannelInternal_SetDocumentURI (0x2affaf8)->()
fixme:mshtml:nsChannel_SetReferrer (0x2affaf8)->(0x2bf3b38)
fixme:shdocvw:ClOleCommandTarget_Exec Unimplemented group
{000214d1-0000-0000-c000-000000000046}
fixme:urlmon:Binding_Abort (0x2b46008)
fixme:shdocvw:ClOleCommandTarget_Exec Unimplemented group
{000214d1-0000-0000-c000-000000000046}
fixme:mshtml:HttpNegotiate_GetRootSecurityId (0x2b162b0)->(0x32f108 0x32f34c 0)
fixme:wininet:InternetLockRequestFile STUB
err:mshtml:read_stream_data buffer is full
--
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=18959
Summary: MetaTrader 4 installer hangs at the very end of file
extraction
Product: Wine
Version: 1.1.23
Platform: PC
URL: http://www.metatrader4.com/files/mt4setup.exe
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: msvcrt
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: arethusa26(a)gmail.com
CC: julliard(a)winehq.org
With today's Git (wine-1.1.23-221-gafce86b), the MetaTrader installer hangs at
the very end of file extraction at "C:\Program Files\MetaTrader
4\mailbox\1190736044.english" with sufficient responsiveness to handle the
Cancel button being pressed, which merely hides the installer window until a
Ctrl+C interrupt is sent to the installer. The installer worked properly in
1.0.1, and the regression test revealed:
1c91d54503f9b2afa513dc4dd79bf19bc9bad51a is first bad commit
commit 1c91d54503f9b2afa513dc4dd79bf19bc9bad51a
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Wed Feb 18 14:44:17 2009 +0100
msvcrt: Don't try to duplicate invalid handles. Don't reset std handles if
we didn't set them.
:040000 040000 2abf5f9a82de1d29b1fccadc658fc3a956388ac4
86464380dfe4aca4c5c11ea2a539a1fc5def03b8 M dlls
Reverting the commit in HEAD allows the installer to start.
--
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=22740
Summary: Lifbase freezes when minimized
Product: Wine
Version: 1.1.44
Platform: x86
URL: http://www.sri.com/psd/lifbase/
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: drakkk(a)centrum.cz
Created an attachment (id=28035)
--> (http://bugs.winehq.org/attachment.cgi?id=28035)
terminal output
When I minimize lifbase there is an error window "Runtime Error '380' Invalid
property value" with OK button. But OK button doesn't respond to mouse click,
program becomes unresponsive and must be manually killed.
--
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=24354
Summary: Webtrends Log Analyzer 6.5c : cannot write BMP files
to disk
Product: Wine
Version: 1.2
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: chris(a)apex-internet.com
Installed Webtrends Log Analyzer 6.5 which works fine, then created a new
profile which also works fine. The problem is when trying to create a new
Report for a profile, it is able to read the web server logs OK, but errors out
when it starts to generate the report to write to disk. The error reported in
Webtrends is:
Unable to extract bmpinfo (using VIC32.DL) from file "C:\Program
Files\WebTrends Log Analyzer\reports\Web
Analysis\TempGraphFiles\ms-2010-0800.bmp"
This BMP file is created, but it is zero bytes in size. At the same time that
this error occurs in Webtrends, in the bash terminal Wine is reporting this
error:
fixme:ole:OLEPictureImpl_SaveAsFile (0x1011dd8)->(0x1017db0, 1, 0x2efde0),
hacked stub.
Here's a link for the Webtrends 6.5c demo:
http://www.tucows.com/preview/195171
--
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=17743
Summary: Undocked toolbars are displayed incorrectly
Product: Wine
Version: 1.0.1
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: lukasz.wojnilowicz(a)gmail.com
Created an attachment (id=19959)
--> (http://bugs.winehq.org/attachment.cgi?id=19959)
Text toolbar
I'm using Wine 1.1.17 (compiled from source using gcc version 4.3.2 20081105
(Red Hat 4.3.2-7) ) on Fedora 10 i386.
The problem is with undocked toolbars which are incorrectly displayed.
The problem is also with dragging them. They should be also draggable when I
click and hold mouse pointer over title of the toolbar.
Problem exists in AutoCAD 2008 and AutoCAD Mechanical 2008.
I attached image that shows the problem. All cuttings were done with unchecked
option "Allow the window manager to decorate the windows". Last cutting was
done in MS Windows XP running AutoCAD 2007. The problem exists also in Wine
1.0.1
--
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=11336
Summary: typing an open parenthesis "(" in vba causes an error
Product: Wine
Version: 0.9.54.
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: ead1234(a)hotmail.com
Created an attachment (id=10442)
--> (http://bugs.winehq.org/attachment.cgi?id=10442)
picture of the error
When programming in VBA under excel the application throws up an error when I
try to enter the open parenthesis
--
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=19153
Summary: DX3 game does not recognize graphics capabilities
Product: Wine
Version: 1.1.24
Platform: PC
URL: http://appdb.winehq.org/objectManager.php?sClass=versi
on&iId=9396
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-ddraw
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: bobbyg(a)gmx.net
Resident Evil 1 does not start giving the error "Failed to initialize the
Graphics Hardware Device.(3)". It's a DirectX 3 game using immediate mode.
After some debugging I found that it relies on 3 (three) entries returned by
EnumDevices whereas wine returns only the Direct3D HAL entry in this case
(d3dversion == 1). Removing the if-clause in ddraw/direct3d.c and duplicating
the HAL entry solves the problem and the game actually runs almost perfectly
(Garbage -> Platinum).
I checked a Windows installation which returns "HAL", "RGB Emulation" and "Ramp
Emulation" but the comments in the file suggest that not all games are happy
about that. So how to fix this properly?
--
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=24308
Summary: Fullscreen fails for MechWarrior 4 games (Only one D3D
device per DirectDraw object)
Product: Wine
Version: 1.3.2
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-ddraw
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: georg298(a)gmx.de
For all MechWarrior 4 games, fullscreen fails with message
fixme:ddraw:d3d7_CreateDevice Only one Direct3D device per DirectDraw object
supported.
Obviously, the game falls back to window'ed mode, as
static HRESULT WINAPI d3d7_CreateDevice(IDirect3D7 *iface, REFCLSID riid,
IDirectDrawSurface7 *surface, IDirect3DDevice7 **device)
returns
DDERR_INVALIDPARAMS
changing this behaviour (returning D3D_OK instead):
if (ddraw->d3ddevice)
{
FIXME("Only one Direct3D device per DirectDraw object supported.\n");
LeaveCriticalSection(&ddraw_cs);
return D3D_OK;
// return DDERR_INVALIDPARAMS;
}
makes fullscreen work for these games.
Probably it's not "legal" to return D3D_OK in this case, but maybe there is a
real solution for this problem?
--
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=10522
Summary: endless WM_PAINT loop bug (update regions, queue paint
count)
Product: Wine
Version: CVS/GIT
Platform: PC
URL: http://www.microsoft.com/whdc/devtools/debugging/install
x86.mspx
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: wine-user
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Created an attachment (id=9265)
--> (http://bugs.winehq.org/attachment.cgi?id=9265)
trace with WINEDEBUG=+tid,+message,+win,+server
Hello,
I've seen this bug a while ago in other apps but ignored it because it was not
easily to reproduce.
Well until recently when I tested some stuff with windbg from "Debugging Tools
for Windows" (Microsoft).
I used debugging tools version 6.8.4.0 and recent GIT
(wine-0.9.49-302-g58b85bb).
Immediately when a child window was opened using toolbar (register, locals, ..
whatever), windbg would become unresponsive, eating most CPU.
Happens in both GUI modes - "floating/docking toolwindow" and "MDI emulation.
Though "MDI emulation" is more obvious, it actually shows the endless
refreshing (window caption).
Attached is WINEDEBUG=+tid,+message,+win,+server log.
Additionally I added a trace message which prints the current queue paint count
(when incremented or fetched) which makes some things easier to spot.
Printed as "inc_queue_paint_count: %d" and "get_message_paint_count: %d".
The window hierarchy is as follows:
--- snip ---
*root*=0x10020
Shell_TrayWnd=0x10022
WinDbgFrameClass=0x10024
DockClass=0x10026
ToolbarWindow32=0x10028
msctls_statusbar32=0x1002a
tooltips_class32=0x1002e
WinBaseClass=0x10030
ToolbarWindow32=0x10032
SysListView32=0x10034
SysHeader32=0x10036
RichEdit20W=0x10038
--- snip ---
After the child windows are created the queue paint count never drops to zero,
resulting in endless WM_PAINT processing.
Maybe some update (region) code path missed or flags problem?
I played a bit with ignoring null region updates and it seemed to help a bit
(preventing endless WM_PAINT loop) though other stuff wasn't drawn properly
then.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.