http://bugs.winehq.org/show_bug.cgi?id=35984
Bug ID: 35984
Summary: Leftover pixels in Microsoft Paint when using
Rectangle tool with thick border
Product: Wine
Version: 1.7.15
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: Nachanon_Vetjasit(a)hotmail.com
Created attachment 48104
--> http://bugs.winehq.org/attachment.cgi?id=48104
Screencast demonstrating the leftover lines problem
I've used Microsoft Paint on WINE, I found that when I set
line thickness to >1px (using Line tool) and select Rectangle tool,
then drag mouse to South-East direction to create a rectangle
(but don't release mouse button yet), then move to West, then North,
and release the button. I'll see that some color pixels that's used to be
old rectangle border were left over.
The larger line size, more obvious the effect.
Apart from leftover lines, there is also a knot on the top left of the
rectangle. (Won't be visible at first glance, use Magnifier tool to see it)
These leftover lines (and knot) also didn't disappear on Undo too.
Screencast demonstrating this problem and affected image also attached.
(Using 5px line thickness in this case).
Microsoft Paint 5.1.2600.5512 (mspaint.exe from Windows XP SP3)
mfc42u.dll 6.2.8071.0 picked from Windows XP SP3, placed with the same
directory as mspaint.exe
WINE: 1.7.15 (git), set to Windows version XP
WINE installed without XInput2, OSMesa, OpenCL, CMS, GStreamer, and OSS support
System: Debian GNU/Linux 5.0 "Lenny" i386
--
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=56797
Bug ID: 56797
Summary: winedevice.exe stalls systemd shutdown/reboot
Product: Wine
Version: 9.9
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: cromachina(a)gmail.com
Distribution: ---
After running random applications in Wine (and subsequently closing them), I've
observed system shutdown being stalled by a systemd message: "A stop job is
running for User Manager for UID 1000", which goes on for about 2 minutes
before forcefully terminating. Upon further investigation, the reason always
seems to be 'winedevice.exe', which seems to be not gracefully handling
SIGTERM. After systemd's timeout, it just sends SIGKILL instead and continues
to shutdown/reboot.
It seems like the correct behavior should be: either systemd asking Wine
services to terminate gracefully should just work without issue or stalls, or
Wine should provide a systemd service that handles calling a shutdown routine
(like calling `wineserver -k` at the right moment).
For some reason, I could not get `wineserver -k` to work at the right time with
a systemd service, however I instead created a service that calls `pkill -9
.exe`, which does work. I'm using NixOS, so I configured the service like so:
systemd.services."wine-shutdown" = {
enable = true;
serviceConfig = {
Type = "oneshot";
RemainAfterExit = true;
ExecStop = "${pkgs.procps}/bin/pkill -9 .exe";
};
before = [ "shutdown.target" "reboot.target" "halt.target" ];
wantedBy = [ "multi-user.target" ];
};
I'm not sure if the programs that were previously ran make a difference, except
that they had ran at all, but I often use Paint Tool SAI and consistently
encounter this shutdown stall situation after using it, so it can be used as a
reference point: https://www.systemax.jp/en/sai/devdept.html
Various reports I've seen across the net exhibiting similar behavior:
https://unix.stackexchange.com/questions/720725/process-winedevice-exe-dela…https://forum.endeavouros.com/t/problem-wine-stop-shutdown-or-reboot/32223/…https://discussion.fedoraproject.org/t/wine-process-delaying-shutdown/68130https://forum.winehq.org/viewtopic.php?t=38189
--
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=53889
Bug ID: 53889
Summary: vbscript does not support Get_Item call on IDispatch
objects
Product: Wine
Version: 7.20
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: vbscript
Assignee: wine-bugs(a)winehq.org
Reporter: jsm174(a)gmail.com
Distribution: ---
I ran into some code with where an IDispatch object has a Get_Item method:
PlayerScores(0).SetValue(1000)
In interp.c, `do_icall` will E_NOTIMPL for REF_OBJ when there are arguments:
if(arg_cnt) {
FIXME("arguments on object\n");
return E_NOTIMPL;
}
To work around this, I added the following:
+ if (arg_cnt) {
+ vbstack_to_dp(ctx, arg_cnt, FALSE, &dp);
+
+ hres = IDispatch_Invoke(ref.u.obj, DISPID_VALUE, &IID_NULL,
+ LOCALE_USER_DEFAULT, DISPATCH_PROPERTYGET, &dp, res,
+ NULL, NULL);
+
+ if(FAILED(hres))
+ return hres;
+
+ IDispatch_AddRef(V_DISPATCH(res));
+
+ break;
+ }
IDispatch_AddRef(ref.u.obj);
V_VT(res) = VT_DISPATCH;
V_DISPATCH(res) = ref.u.obj;
--
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=56796
Bug ID: 56796
Summary: G5 installer crashes on start
Product: Wine
Version: 9.9
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dark.shadow4(a)web.de
Distribution: ---
Created attachment 76601
--> https://bugs.winehq.org/attachment.cgi?id=76601
Wine log
Download at https://www.g5.com/de/appDownload/1036
Main issue seems to be
> Unhandled Exception: System.Windows.Markup.XamlParseException: The invocation of the constructor on type 'G5LauncherSetup.MainWindow' that matches the specified binding constraints threw an exception. ---> System.TypeLoadException: Could not find Windows Runtime type 'Windows.Management.Deployment.PackageManager'.
Which is a bit weird, since this class seems to be implemented (at least stubs)
in Wine.
--
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=56782
Bug ID: 56782
Summary: MySims does not display text.
Product: Wine
Version: 9.10
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: hibbsncc1701(a)gmail.com
Distribution: ---
Created attachment 76583
--> https://bugs.winehq.org/attachment.cgi?id=76583
Clean prefix console log.
As the summary says, the game does not display any text. Menus, dialogs,
in-game, etc.
Installing core fonts does nothing.
Console log attached.
--
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=56795
Bug ID: 56795
Summary: Windows version is detected as outdated by
XboxInstaller.exe
Product: Wine
Version: 9.10
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: tobil4sk(a)outlook.com
Distribution: ---
The Xbox App installer has a minimum requirement of Windows 10 19H1 or higher.
However, even when the version is set to 10 or 11, the app shows a message
saying that the version is outdated and that an update has to be performed
before the installer can run.
The GetVersionExW() function in dlls/kernelbase/version.c is returning version
information for Windows 8 instead of 10. This happens because of this line in
init_current_version, where the RtlImageNtHeader has the version 4.0 so it
defaults to Windows 8 as the reported version.
https://gitlab.winehq.org/wine/wine/-/blob/951e0e27a743e52c75c7fedc0b1eaa9e…
This looks intentional, so maybe the real issue is that the
IsWindows[x]OrGreater functions are missing from wine.
Note, it is only possible to start the app without crashing if this patch is
applied:
https://gitlab.winehq.org/wine/wine/-/merge_requests/5771
--
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=56547
Bug ID: 56547
Summary: New Alpha Protocol GOG Release Fails to Launch
Product: Wine
Version: 9.5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: nekoNexus(a)protonmail.ch
Distribution: ---
Created attachment 76303
--> https://bugs.winehq.org/attachment.cgi?id=76303
Wine-9.5 Terminal Output Log
Distro: Gentoo Linux 64-bit (LLVM-based)
Wine Version: 9.5 (Built with GGC & MingW)
Wine Compile Flags:
CFLAGS="-march=znver2 -pipe -O2 -ggdb3"
CXXFLAGS="${CFLAGS} -Wp,-D_GLIBCXX_ASSERTIONS"
LDFLAGS="-Wl,-O2,--sort-common,--as-needed"
-----
Store Page:
https://www.gog.com/en/game/alpha_protocol
-----
Summary:
--------
After installing GOG's re-release of Alpha Protocol, the game fails to properly
launch and throws a backtrace window instead.
--
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=17195
Summary: NamedPipe datagrams need to be _really_ datagrams
Product: Wine
Version: unspecified
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: lkcl(a)lkcl.net
ok, after a little bit of investigation, i think i understand the pipes code
enough to be able to say what's going on, and i'm seeing something like this:
process 1:
recvpipe = CreateNamedPipe("\\pipe\fred")
ReadFile(recvpipe, buffer, &length);
printf(length) ===> 43
ReadPipe(recvpipe, buffer, &length); /* no data */
process 2:
sendpipe = CreateNamedPipe("\\pipe\fred")
length = 9;
WriteFile(sendpipe, buffer, &length);
length = 34;
WriteFile(sendpipe, buffer, &length);
what's happening is that the data being sent down the pipes isn't being done as
datagrams. the implementation is using a stream-based fd.
the solution is: you _must_ implement a protocol on top of the pipes which
sends the length (as a 32-bit int, whatever) which is read off the fd, followed
by the data stream of _exactly_ that length.
_must_. there's no two ways about this.
the protocol of Pipes is unfortunately a combination of both datagrams and
streams. datagrams because the lengths of data sent are absolute and
inviolate. streams because the data order and reliability are _also_ absolute
and inviolate.
you can't use datagrams (because they're unreliable). you can't expect all
unixen to support datagrams on top of unix sockets (if that's what's being
used).
so - you have to send the length, as part of the implementation of the
pipe-data-send.
sending a length will also solve the issue of trying to send zero-length pipe
datagrams.
as a first implementation, you _might_ be able to get away with assuming that
when someone asks for some data, they _will_ provide a buffer big enough.
... actually... i don't see any ERR_MORE_DATA error codes in NtReadFile, so
that would explain... this is going to get messy :)
--
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=56783
Bug ID: 56783
Summary: MySims doesn't render the character creation screen
Product: Wine
Version: 9.10
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: d3d
Assignee: wine-bugs(a)winehq.org
Reporter: hibbsncc1701(a)gmail.com
Distribution: ---
Created attachment 76584
--> https://bugs.winehq.org/attachment.cgi?id=76584
Character creation black screen
When starting a new game, the game will first display a few 2D images detailing
the game's plot. Afterwards the player will be taken to the character creation
screen for them to create their sim. Under wine-9.10 this screen is completely
black minus the in-game UI elements.
(Also in wine-9.10 this screen doesn't show any text. See also: Bug #56782.)
--
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=55613
Bug ID: 55613
Summary: right click does not work in Battle.net App (friends
list, favorite games)
Product: Wine
Version: 8.16
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: kolAflash(a)kolahilft.de
Distribution: ---
Right click does not work in Battle.net (Blizzard).
Battle.net App version: 2.24.1.14385 (2023-09-17)
Right click is mostly being needed for managing contacts in the friends list at
the right side and favorite games in the top bar. In both cases right click is
supposed to open a context menu.
Console output when right clicking:
0118:fixme:system:EnableNonClientDpiScaling (00050116): stub
0118:fixme:shell:SHGetPropertyStoreForWindow (00050116 112451A8 0060B018) stub!
0118:fixme:shell:window_prop_store_SetValue 1B806B70,
{{9f4c2855-9f79-4b39-a8d0-e1d42de1d5f3},4}, 0060B008
0118:fixme:shell:window_prop_store_SetValue 1B806B70,
{{9f4c2855-9f79-4b39-a8d0-e1d42de1d5f3},2}, 0060AFF8
0118:fixme:shell:window_prop_store_SetValue 1B806B70,
{{9f4c2855-9f79-4b39-a8d0-e1d42de1d5f3},3}, 0060AFE8
0118:fixme:shell:window_prop_store_SetValue 1B806B70,
{{9f4c2855-9f79-4b39-a8d0-e1d42de1d5f3},5}, 0060AFD8
0118:fixme:shell:window_prop_store_Commit 1B806B70
0118:fixme:win:GetPointerDevices (0060CCAC 00000000): partial stub
0118:fixme:system:NtUserQueryDisplayConfig flags 0x2, paths_count 0x60ccac,
paths 0x1addd280, modes_count 0x60cca8, modes 0x1ad59340, topology_id (nil)
semi-stub
0118:fixme:system:NtUserDisplayConfigGetDeviceInfo Unimplemented packet type
11.
Workaround:
Enable the virtual desktop in winecfg or using the /explorer switch.
https://wiki.winehq.org/Winecfg#Window_Settingshttps://wiki.winehq.org/Explorer
Unfortunately you can't switch between different "Windows application" windows
using ALT-TAB in this mode.
And when you use ALT-TAB to switch to other X windows, this may cause the
Windows applications to assume that the ALT key is being stuck hold down. This
is probably another bug, but I can't find a bug report for it. (feel free to
create a bug report and link it here, if you encounter this problem)
See also:
https://www.reddit.com/r/wine_gaming/comments/ou67et/right_clicking_on_batt…https://www.reddit.com/r/linux_gaming/comments/141oitc/right_click_on_battl…
--
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.