https://bugs.winehq.org/show_bug.cgi?id=50812
Bug ID: 50812
Summary: Astrology software Parashara light 9 (PL9) is not
working via wine on linux mint.
Product: Wine
Version: 6.4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: aks(a)hotmail.co.in
Distribution: ---
Created attachment 69623
--> https://bugs.winehq.org/attachment.cgi?id=69623
Bug report attached.
Astrology software (Licensed version) windows based which run via donggal is
not working.
I am using linux mint 20.
The astrology software (PL9- the latest version) is installed via wine but not
working where as old version of the astrology software (PL2000) is working
nicely.
I have attached the bug report.
I request you please resolve it.
--
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=50145
Bug ID: 50145
Summary: Wrong colors in movies in Lego raiders
Product: Wine
Version: 5.21
Hardware: x86
URL: https://www.myabandonware.com/game/lego-rock-raiders-b
ci#download
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: quartz
Assignee: wine-bugs(a)winehq.org
Reporter: jeremielapuree(a)yahoo.fr
Distribution: Ubuntu
Created attachment 68649
--> https://bugs.winehq.org/attachment.cgi?id=68649
Screenshot showing the problem.
With wine 5.21, intro movies play. But colours are wrong. I compared with the
colours in a real windows XP box. The screenshot is taken from the third intro
movie. But even the first one shows wrong colours.
--
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=49328
Bug ID: 49328
Summary: Lego raiders crash with native d3drm and native
amstream
Product: Wine
Version: 5.10
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winegstreamer
Assignee: wine-bugs(a)winehq.org
Reporter: jeremielapuree(a)yahoo.fr
Distribution: Ubuntu
Created attachment 67360
--> https://bugs.winehq.org/attachment.cgi?id=67360
console ouput of the crash
With native d3drm and native amstream, lego raiders crash.
--
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=44355
Bug ID: 44355
Summary: FaceIt client : www.faceit.com/client
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: adil3.7896(a)gmail.com
Distribution: ---
Created attachment 60250
--> https://bugs.winehq.org/attachment.cgi?id=60250
Backtrace of the issue
The FaceIt client was running properly when it suddenly closed with the
following message: ...have to close the application due to Database issues.
Please check Wine Application Database for more information.
Here's the backtrace (attachment)
please fix?
--
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=41713
Bug ID: 41713
Summary: Explorer.exe is wrong when started from the process
creating the Wine prefix
Product: Wine
Version: 1.9.8
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
To reproduce this do the following:
rm -rf ~/.wine
cd dlls/shell32/tests
rm shelldispatch.ok
make shelldispatch.ok
This normally results in the following failure:
shelldispatch.c:624: Test failed: got 0x80040152
Which corresponds to the following line:
ok(hr == S_OK, "got 0x%08x\n", hr);
/* TODO: remove when explorer startup with clean prefix is fixed */
if (hr != S_OK)
return;
The workaround is to ensure the Wine prefix has been created before running the
test:
rm -rf ~/.wine
./wine hostname
./server/wineserver -w
cd dlls/shell32/tests
rm shelldispatch.ok
make shelldispatch.ok
Note that wt-daily is now implementing this workaround (see
https://github.com/fgouget/wt-daily).
--
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=50815
Bug ID: 50815
Summary: Change UNCONFIRMED/NEW statuses to OPENED
Product: WineHQ Bugzilla
Version: 3.2.3
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: bugzilla-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: gijsvrm(a)gmail.com
CC: austinenglish(a)gmail.com
Distribution: ---
This has been a long standing cause of user confusion, so it might be a good
idea to change it.
It will inadvertently cause less spam on bugs, because users will no longer
post comments to ask why a bug is still listed UNCONFIRMED instead of NEW, even
though we don't currently make a distinction.
--
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=50817
Bug ID: 50817
Summary: Photoshop CC (all versions) reset windows position
when click on them
Product: Wine
Version: 6.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jeff.artik(a)gmail.com
Distribution: ---
Created attachment 69630
--> https://bugs.winehq.org/attachment.cgi?id=69630
Video of the windows behavior. Each reset position is due to a click on it
(don't pay attention to top flickerings due to record program)
Display any window (preferences, settings, layers styles), move it then click
on them again reset their position.
Can be annoying in the case it constantly cover the picture we're working on,
especialy the Layer styles window.
.mp4 attached shows the bug occuring each time I click on the window (not
matter where)
--
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=45232
Bug ID: 45232
Summary: TIDAL can't be installed with exe installer
Product: Wine
Version: 3.8
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ieframe
Assignee: wine-bugs(a)winehq.org
Reporter: dark.shadow4(a)web.de
Distribution: ---
Created attachment 61461
--> https://bugs.winehq.org/attachment.cgi?id=61461
Wine log
The program instantly crashes, I assume due to the missing ieframe interface.
Needs wine-staging patches, else it complains about being run as administrator.
--
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=45749
Bug ID: 45749
Summary: Visual Studio 2017 Installer fails due to
node.js/libuv listen(named pipe) error
Product: Wine
Version: 3.14
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jimbo1qaz(a)gmail.com
Distribution: ---
Created attachment 62190
--> https://bugs.winehq.org/attachment.cgi?id=62190
Visual Studio Installer logs (mostly useless)
Running Kubuntu 18.04 64-bit. I created a 32-bit .wine32 prefix, installed
dotnet46 via winetricks, then the Build Tools for Visual Studio installer
(https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio…
) (which shares the core with VS2017 installer. It's written in node.js and
involves multiple processes communicating via what the source describes as
"pipe"s).
The error is "Hub Controller process exited prematurely with exit code 1
(NodeUncaughtFatalException)."
Interestingly, the installer's source is user-readable and located in
WINEPREFIX / drive_c/Program Files/Microsoft Visual
Studio/Installer/resources/app/node_modules/microsoft-servicehub/host/. I was
able to edit the .js files to add control flow logging:
const fs = require('fs');
function logg(val, args){
fs.writeFileSync("C:\\"+process.hrtime()[1] + '_'+val, ""+args,
function(err) {});
}
Installer seems to be codenamed "microsoft-servicehub". Strangely, many of the
Installer files appear to test for Windows and/or *nix, despite VS being
Windows-only. It also references open-source VS Code, but I was unable to find
any hits when Googling for quoted strings.
----------
The error message "Hub Controller process exited prematurely with exit code" is
raised from within "drive_c/Program Files/Microsoft Visual
Studio/Installer/resources/app/node_modules/microsoft-servicehub/controllerConnection.js":
ControllerConnection.prototype.startController `var connectPromise` fails,
calling `function (err)` to spawn a process (which crashes).
ControllerConnection.prototype.onControllerProcessExited is responsible for
noticing the process has terminated, and raising the exception.
---------
The actual crash originates from "drive_c/Program Files/Microsoft Visual
Studio/Installer/resources/app/node_modules/microsoft-servicehub/host/HubController.js".
HubController.js is executed by several distinct processes, and `process.pid`
is the same within `function HubController()` and the global scope.
I systematically replaced all calls to `logger.error()` (info, etc.) to
`logg()` (since Logger.error() called within subprocess did not show up in
Visual Studio's debug logs). I get two sequentially numbered files, 1
millisecond apart:
"429988399_Successfully started server on pipe
5d74f51d8cc5d690c261c26d3e9e3408e060bd352875558b9320be9c213e0610"
"430873100_Terminating controller due to some unknown error: " with contents
"listen EINVAL
\\?\pipe\5d74f51d8cc5d690c261c26d3e9e3408e060bd352875558b9320be9c213e0610"
This error is thrown by `function retryStartServer`. `e.code` is EINVAL, while
the code only handles `e.code === ec.EADDRINUSE.code`.
Looking at
https://stackoverflow.com/questions/11040460/get-the-listen-einval-when-sta…
suggests:
> > EINVAL The socket is already connected.
> Make sure something isn't already listening on that port.
`man errno` suggests otherwise: > EINVAL Invalid argument (POSIX.1-2001).
Adding `|| e.code === ec.EINVAL.code` and commenting `process.platform ===
'win32' ||` sends the installer into an endless "kill and restart
HubController" loop, which isn't what we want.
Extra notes on control flow at
https://gist.github.com/jimbo1qaz/1c972422fd5c31706920b9be5c2a0f42#server
--------
The `EINVAL` error comes with a node.js stack trace:
https://gist.github.com/jimbo1qaz/1c972422fd5c31706920b9be5c2a0f42#file-net…
(The hexadecimal path originates from
https://gist.github.com/jimbo1qaz/1c972422fd5c31706920b9be5c2a0f42#determin…
)
https://github.com/nodejs/node/blob/68dff4a67b7222770f90fc5d9bdd884f8db4a24…
`const ex = new Error(`${syscall} ${code}${details}`);`
"listen EINVAL
\\?\pipe\5d74f51d8cc5d690c261c26d3e9e3408e060bd352875558b9320be9c213e0610"
I think the call which failed is `listen`, which returns EINVAL for some
reason.
------------
Comparing my stack trace with node.js source code (node.dll 8.9.3):
`Server.listen (net.js:1487:5)` =
https://github.com/nodejs/node/blob/v8.9.3/lib/net.js#L1487
- listenInCluster(server=this, address=pipeName, port=-1, addressType=-1,
backlog=backlog, fd=undefined, exclusive=options.exclusive);
`listenInCluster (net.js:1392:12)` =
https://github.com/nodejs/node/blob/v8.9.3/lib/net.js#L1392
- server._listen2(=address, =port, =addressType, =backlog, =fd);
Unpeeling layers of abstraction on top of Windows named pipes:
`Server.setupListenHandle [as _listen2] (net.js:1351:14)` =
https://github.com/nodejs/node/blob/v8.9.3/lib/net.js#L1351
(Bullet points are not in stack trace, but I assume they executed)
- `handle = new Pipe(PipeConstants.SERVER);`
https://github.com/nodejs/node/blob/v8.9.3/lib/net.js#L1267
- `const { Pipe } = process.binding('pipe_wrap');` which refers to C++ code
at https://github.com/nodejs/node/blob/v8.9.3/src/pipe_wrap.cc
- pipes are handled by https://github.com/libuv/libuv
- `var err = this._handle.listen(backlog || 511);` is the operation which fails
=
https://github.com/nodejs/node/blob/8a44289089a08b7b19fa3c4651b5f1f5d1edd71…
- Routes to https://github.com/nodejs/node/blob/v8.9.3/src/pipe_wrap.cc#L154
- which calls uv_listen(). `return uv_translate_sys_error(err);` and EINVAL is
located at https://github.com/libuv/libuv/blob/v1.x/src/win/error.c#L101 ...
There are 7 Win32 errors all mapping to UV_EINVAL==EINVAL, but only WSAEINVAL
can happen.
- uv_listen() either [assert(0) and sets err=ERROR_INVALID_PARAMETER] (I hope
not), calls uv_tcp_listen (I hope not)
- Most likely calls uv_pipe_listen() =
https://github.com/libuv/libuv/blob/1391a3d9d0996fcf1a116a9c6c58e8b1c730319…
- It has 4 return paths, only `if (!(handle->flags & UV_HANDLE_BOUND)) { return
WSAEINVAL;` is happening =
https://github.com/libuv/libuv/blob/1391a3d9d0996fcf1a116a9c6c58e8b1c730319…
- What initializes `handle->flags` without |=UV_HANDLE_BOUND?
ok i'm getting a headache
--
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.