http://bugs.winehq.org/show_bug.cgi?id=27982
Summary: Creative Writer 2 hangs on startup
Product: Wine
Version: 1.3.25
Platform: x86-64
URL: http://download.cnet.com/Microsoft-Creative-Writer/300
0-13455_4-15232.html
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winmm&mci
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: RandomAccountName(a)mail.com
CC: aeikum(a)codeweavers.com
Created an attachment (id=35817)
--> (http://bugs.winehq.org/attachment.cgi?id=35817)
Terminal output
In 1.3.25 (and git), Creative Writer 2 can no longer start correctly. It only
shows a Microsoft logo (trial) or blank window (full version) and hangs.
Regression testing indicated:
be158e48ad8ee556941bd3f1ff94ca7116680d00 is the first bad commit
commit be158e48ad8ee556941bd3f1ff94ca7116680d00
Author: Andrew Eikum <aeikum(a)codeweavers.com>
Date: Mon Jul 11 08:28:30 2011 -0500
winmm: Implement waveOut* on top of MMDevAPI.
:040000 040000 428f760df6efda7a37b4a84f97721523ab72863f
2b94a3c0b7a42f4f83b037adc317d17565c1f7a9 M dlls
--
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=26689
Summary: Creative Writer 2 crashes after opening some sets of
files consecutively
Product: Wine
Version: 1.3.17
Platform: x86-64
URL: http://download.cnet.com/Microsoft-Creative-Writer/300
0-13455_4-15232.html
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ole32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: RandomAccountName(a)mail.com
Created an attachment (id=33986)
--> (http://bugs.winehq.org/attachment.cgi?id=33986)
Output from wine-1.3.17-147-g0b8bfd9
Creative Writer 2 can crash while attempting to open a previously saved file if
another file is already loaded. Not all pairs of files cause a crash, though.
Steps to reproduce with the trial version:
1. Click OK to an error and an introduction at startup
2. Choose to open a file (via the icon in the lower-left of the new project
dialog)
3. Open "Creative Writer Card.max"
4. Click the folder icon at the top of the screen, then "open..."
5. Open "Creative Writer Project.max"
The program crashes. However, there's no problem when opening those files in
the opposite order. Native ole32 prevents the crash.
--
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=25155
Summary: Creative Writer 2 only installs in Win9x modes on
WoW64
Product: Wine
Version: 1.3.7
Platform: x86-64
URL: http://download.cnet.com/Microsoft-Creative-Writer/300
0-13455_4-15232.html
OS/Version: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: programs
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: RandomAccountName(a)mail.com
Creative Writer 2 fails to install on a 64-bit prefix with the message "this
setup program is not intended to be used with your version of Windows" unless
the reported Windows version is changed to 95/98/ME. There's no terminal output
at this point. A regression test identified this commit as the cause:
8ac60d56b6d02a773b915e6e1389c5c070bfa633 is the first bad commit
commit 8ac60d56b6d02a773b915e6e1389c5c070bfa633
Author: Konrad Wartke <kwartke(a)gmail.com>
Date: Sun Aug 15 18:54:47 2010 +0200
wineboot: Added more architectures in create_enviroment_registry_keys.
:040000 040000 f05d81751b1c1d81deeeae56a56cdf57331075f0
05376598d93907a6f2f53d3f603a6dfb1a8e6e18 M programs
Reverting that patch fixes the 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=23817
Summary: Creative Writer 2 trial can't show images in .max
files
Product: Wine
Version: 1.2
Platform: x86-64
URL: http://download.cnet.com/Microsoft-Creative-Writer/300
0-13455_4-15232.html
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ole32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: RandomAccountName(a)mail.com
Created an attachment (id=29883)
--> (http://bugs.winehq.org/attachment.cgi?id=29883)
Standard output
When one of the sample .max files included with the Creative Writer 2 trial is
opened, images embedded in the file are not displayed at all. It's a regression
that I noticed while trying to get some ancient Wine versions to work on my
system, but the images are still missing in current git.
878d5e9cec42408e36b0fac05d7ee2b6d6d48196 is first bad commit
commit 878d5e9cec42408e36b0fac05d7ee2b6d6d48196
Author: Rob Shearman <rob(a)codeweavers.com>
Date: Mon Dec 4 15:51:20 2006 +0000
ole32: Implement the GetData function of the data cache to using the
existing LoadData function and fix GetData to also return data that
has been set, rather than loaded.
:040000 040000 9c2d3dc4adb87675e96176b799aef86689982443
b4dafea9a3f279efe226225cba2f8468322143a1 M dlls
Reverting that patch from an ancient version results in images displaying
correctly again. Trying to revert from wine-1.2-495-g20f51c2 gives "Unreversed
patch detected!"..."2 out of 2 hunks ignored". Steps to reproduce:
1. Click OK to some messages on startup and choose to start "a blank page"
2. Click the folder icon toward the upper-right and choose "open"
3. Open the file "Creative Writer Project.max"
Expected result: a drawing of a dog with the words "caution! beware of dog"
should be shown, as seen in the preview on the file selection screen
Actual result: A blank red page is displayed
--
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=21822
Summary: Creative Writer 2's interface is the wrong colors
unless running at 8-bit color depth
Product: Wine
Version: 1.1.39
Platform: x86-64
URL: http://download.cnet.com/Microsoft-Creative-Writer/300
0-13455_4-15232.html
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winex11.drv
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: RandomAccountName(a)mail.com
CC: julliard(a)winehq.org
Created an attachment (id=26412)
--> (http://bugs.winehq.org/attachment.cgi?id=26412)
Terminal output
I thought I'd see how this old program works with Wine, and it turns out that
most of the interface is the wrong colors. The program's messages are
unreadable because the black text appears on a black background, and the rest
of the interface is mostly red and black. However, it displays correctly if
Xephyr is used to run the program at 8-bit color depth. I tried it in an older
version and found that this is a regression:
77b9b8a307711bd1f6da30f7d2d5e04faa3f5092 is first bad commit
commit 77b9b8a307711bd1f6da30f7d2d5e04faa3f5092
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Wed Sep 30 20:39:51 2009 +0200
winex11: Move the DIB locking and the client-side optimizations into
BITBLT_InternalStretchBlt.
This way they also apply to the non-stretching StretchBlt case.
:040000 040000 5258f614d1fbad21afb6b17eed2620efdc8bd430
f94133cfd7d440fe9ac4e51c5d9d934795ae1125 M dlls
Both the trial and retail version are affected. I'll attach good and bad
screenshots of the program shortly.
There are other open regressions created by this commit - bug 20565 and bug
21067 - but I don't know whether this is exactly the same problem as one of
those or not.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=43685
Bug ID: 43685
Summary: Many games fail to start or run without audio using
the git version of Wine
Product: Wine
Version: 2.16
Hardware: x86
OS: Linux
Status: NEW
Keywords: regression
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: gyebro69(a)gmail.com
CC: julliard(a)winehq.org
Regression SHA1: a0f64e1231a88417fe8b6e3eb459b2c8a098aec6
Distribution: ---
I have problems running many of my games in the current git version
(wine-2.16-77-g917e86dd7a).
Some of the affected games crash after start (without a usable backtrace),
other games do run but audio doesn't work in these games. In the terminal I see
at least 3 different errors:
1. for the games that crash there are lots of these errors before the crash:
err:d3d:wined3d_debug_callback 0x1943e0: "GL_OUT_OF_MEMORY error generated.
Failed to allocate CPU address space mapping for texture (consider building
64-bit app).".
err:d3d:wined3d_debug_callback 0x1943e0: "GL_INVALID_VALUE error generated.
Size and/or offset out of range.".
(0) : fatal error C9008: out of memory - malloc failed
2. the games that run without audio are showing this in the terminal:
mmap() failed: Cannot allocate memory
Failed to create permanent mapping for memfd region with ID = 2216594112
Ignoring received block reference with non-registered memfd ID = 2216594112
ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave
3. for some games the crash is preceded by these:
err:module:load_builtin_dll failed to load .so lib for builtin L"DBGHELP.DLL":
/home/gyebro/sources/wine-git/dlls/dbghelp/dbghelp.dll.so: failed to map
segment from shared object
err:module:load_builtin_dll failed to load .so lib for builtin L"DBGHELP.DLL":
/home/gyebro/sources/wine-git/dlls/dbghelp/dbghelp.dll.so: failed to map
segment from shared object
wine: Unhandled page fault on read access to 0x00000000 at address 0x7dcaadec
(thread 0045), starting debugger...
The problem doesn't occur before
commit a0f64e1231a88417fe8b6e3eb459b2c8a098aec6
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Wed Sep 6 09:58:18 2017 +0200
ntdll: Allocate views out of a memory block instead of using a heap.
Many games built on the Unreal Engine 3 will fail due to this commit. One
example is Alien Breed: Impact. This game has a demo on Steam, but I couldn't
try if the demo has the same problem as the full version.
http://store.steampowered.com/app/22610/Alien_Breed_Impact/
wine-2.16-77-g917e86dd7a (32-bit)
Arch Linux 64-bit
Nvidia binary driver 384.69
I tried these games with nouveau/mesa-17.1.8 too, with similar results. Instead
of showing those ""GL_OUT_OF_MEMORY error generated..." errors in the terminal,
many games fail with such errors:
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 155 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Value in failed request: 0x0
Serial number of failed request: 189
Current serial number in output stream: 193
--
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.
https://bugs.winehq.org/show_bug.cgi?id=51532
Bug ID: 51532
Summary: WDC 1.17.396 - a Wolfenstein 3d game editor fails to
start
Product: Wine
Version: 6.13
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jeffz(a)jeffz.name
Distribution: ---
Run the installer: https://www.wolfenvault.com/files/utilities/WDC-1.17.396.exe
It says it requires vb6, so `winetricks vb6run`
jeffz@darkstar:~/.wine-w3d/drive_c/WDC$ WINEPREFIX="/home/jeffz/.wine-w3d" wine
C:\\\\WDC\\\\WDC.exe
00f4:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
(repeated a bunch of times)
0034:fixme:font:get_name_record_codepage encoding 29 not handled, platform 1.
(repeated a bunch of times)
No window appears, it exits almost immediately.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=51400
Bug ID: 51400
Summary: failed to launch UI information server
Product: Wine
Version: 6.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: windowscodecs
Assignee: wine-bugs(a)winehq.org
Reporter: susancragin(a)earthlink.net
Distribution: ---
Created attachment 70256
--> https://bugs.winehq.org/attachment.cgi?id=70256
run log
This may be a regression.
My program ran fine with wine-6.11 (Staging) and I just downloaded wine-6.12
(Staging) and now when I launch it, it fails very early with this message:
failed to launch UI information server
My app is Dragon Naturally Speaking 12.5.
I should mention that the program sometimes throws up miscellaneous error
messages prior to starting, but I have never gotten this message, and the error
messages have never stopped the program from opening.
I run Gentoo.
Dragon NaturallySpeaking comes with its own Net 4.0 framework, so I do not use
Mono.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=51530
Bug ID: 51530
Summary: MeGUI: processing AVS script conversion on large
source file fills disk to 100% with intermediate
processing file
Product: Wine
Version: 6.13
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gdiplus
Assignee: wine-bugs(a)winehq.org
Reporter: tigerwild(a)gmail.com
Distribution: ---
Generated .avs script converting non-interlaced MPEG-2 (DVD standard) into x265
then final output to be muxed within .mkv container.
I identified that long start times when opening content appear to be caused by
the the intermediate processing of files. The AVS script pipes data from one
process to another, and I noted that the initial process of Ffmpeg output, was
not staying constrained to ram. Instead it was being written to disk while also
not being forwarded to the encoder until AFTER it had completely processed the
input video file.
The intermediate processing and storage of uncompressed frames data generated
prior to handoff to x265 encoder rapidly fills 100+ GB of disk file space,
typically on root drive as this is where Wine (
/home/username/.wine/drive_c/users/username/Temp ) directory is located.
Testing by converting just a small number of frames where the intermediate
files created did not completely fill up the hard disk were 100% successful
with the only performance bump compared to Windows being the intermediate
writing of the files to the hard drive.
Steps to reproduce:
Install
wine-6.13 ( staging )
Execute
Executed WineCFG, configure default Windows version to 2008 or Windows 7
Install
winetricks
Download
As Microsoft no longer supports fileshare of windows6.1-KB976932-X64.exe, I
downloaded a copy from https://archive.org/details/windows6.1-KB976932 .
Place the file into /home/username/.cache/winetricks/win7sp1 [ it's a 903 MB
file! ]
Get the official MeGUI 2913 x32 from
https://sourceforge.net/projects/megui/files/ .
Extract and place the files into /home/username/.wine/drive_c/Program Files
(x86)/MeGUI-2913-32
Execute
winetricks, perform 'Install an application',
with no application selected pressed 'cancel', then select 'Install a Windows
DLL or component', then select 'dotnet40'.
winetricks, perform 'Install an application',
with no application selected pressed 'cancel', then select 'Install a Windows
DLL or component', then selected 'gdiplus'.
WineCFG, select 'Add application' and manually navigate to the directory; I
selected MeGUI.exe and set version to either Windows 2008 / 7. Both worked in
testing.
MeGUI, note: I got multiple error windows prior to program finally showing up
for use on screen. Wine performed two reconfigurations and proceeded some 20
seconds before the application was usable.
Behaviour:
Root drive is filled to capacity very quickly reaching 99.99% useage and
forcing OS to ask to free up space. MeGUI task monitor shows no progress during
this time. The /home/username/.wine/drive_c/users/username/Temp directory is
filled with files which appear to be the uncompressed video frames coming from
FFMPEG's processing, prior to being piped to the x265 encoder.
Expected behaviour:
Each process should be constrained to RAM for fastest processing, vice writing
the ouputs to disk. Also the pipe from one process to the next should happen
immediately upon reaching a filled capacity (eg. 90% filled buffer).
Additional information:
Typical command line that MeGUI generates for actually performing its processes
is similar to the following Job command line:
"cmd.exe" /c ""C:\Program Files (x86)\MeGUI-2913-32\tools\ffmpeg\ffmpeg.exe"
-loglevel level+error -i "Z:\media\PcName\Data\Archive\Video
Captures\MyDvDContent.mkv.avs" -strict -1 -f yuv4mpegpipe - | "C:\Program Files
(x86)\MeGUI-2913-32\tools\x265\x64\x265.exe" --preset faster --tune grain --crf
21.9 --sar 1:1 --output "Z:\media\PcName\Data\Archive\Video
Captures\MyDvDContent.mkv.hevc" --frames 163130 --y4m -"
--
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.
https://bugs.winehq.org/show_bug.cgi?id=50499
Bug ID: 50499
Summary: SO_REUSEADDR compatibility problems
Product: Wine
Version: 6.0-rc6
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: James(a)superbug.co.uk
Distribution: ---
The use case I am struggling with is the use of a Windows program
running in wine that is sending and receiving UDP packets.
This particular windows program uses SO_REUSEADDR socket option and
opens two sockets. Lets call the first one socket A, and the second
one Socket B.
The SO_REUSEADDR from the Windows application is translated by "wine" into a
SO_REUSEADDR in Linux.
Unfortunately the behaviour of these is different between Windows and
Linux so the Windows application fails to run on Linux under wine.
1 ) On windows:
All received unicast UDP packets will arrive on the first opened
socket. Thus on socket A.
2) On Linux:
All received unicast UDP packets will arrive on the last opened
socket. Thus on socket B.
The problem is that this windows program only expects to receive
unicast UDP packets on socket A, and thus it sees no packets.
There are no currently existing socket options in Linux that would
permit wine to simulate the Windows behaviour.
And thus, the reason I am asking the question here.
Please can we add an extra socket option to the Linux socket options
such that we can get wine to simulate Windows correctly. I.e. behave
like (1) above.
Now wine is pretty good at simulating most things Windows throws at
it, but socket options is not one of them yet.
Also note, that (1) is actually more secure than (2) because it
prevents other applications with the same UserID from hijacking the
socket.
Although (2) is more helpful in more gracefully handling some error edge cases.
Suggested new option name: SO_REUSEADDR_WS
--
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.