http://bugs.winehq.org/show_bug.cgi?id=2082
Stian Low <wineryyyyy(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wineryyyyy(a)gmail.com
--- Comment #179 from Stian Low <wineryyyyy(a)gmail.com> ---
(In reply to Zeb Figura from comment #177)
> (In reply to chaosesqueteam from comment #176)
> I really don't know where you're getting this from. You have started posting
> on this bug tracker less than two weeks ago.
> Please stop adding noise and complaints to bugs.
My interactions with chaosesqueteam recently have felt like interacting with a
bot and/or troll.
Google search the account and you'll find suspicious suspect activity.
Already suspended from Blender community:
https://blenderartists.org/t/suspension-reports/1465069/6
--
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=2082
--- Comment #178 from chaosesqueteam(a)sogetthis.com ---
(In reply to Zeb Figura from comment #177)
I've been programming for free software since 2001.
24 years. Been using wine a similar amount of time.
Diablo 1 always worked to some degree or another as far as I can remember.
I just tried forcing it now to a windowed mode using DxWnd (note: in OSX); only
got to see the red bottom of the screen (up from being all black in full screen
mode): and then it crashed.
This is a regression as far as I can tell.
And yes: in free software/ opensource, things are just dismissed and labeled
won't fix now. As if it's a professional corporate environment. Started since
someone decided to attempt to extract slave labour from graduates by requiring
opensource contributions for job placement.
Forcing the unwilling (or coercing) to interact with opensource just destroys
the culture that caused its success.
And the removal of that culture is causing regressions and failure. From the
removal of ReiserFS because it's "unmaintained" (this was never a requirement:
we used not look a gift horse in the mouth and were grateful for any
contributions of code from anyone) with the underlying reason being that it's
author is hated by the new people who have replaced the hackers that once built
everything in this subject, to various other speech-code related enforcements
(codes of conduct): contribution from actual hackers has been
"DEEPRECIATTTEEED" (again: we never used to "DEEPREEECIATE" anything: working
on old hardware, working with the same configs for decades since the 70s and
80s was a point of pride in linux and the bsds.) and has largely been ceased.
People like Hans Reiser are not "allowed" to contribute to opensource
anylonger: where as the previous mantra; and promise; was code is what
mattered: not character (not that there is anything wrong with Reiser's
character: he's a man of brutal and direct action: something the hackers who
created free software didn't have any opinion either way about)
Things are now ripped out of opensource because of who the author is, and what
he believes, and what he did to the beloved class of new-testament coded
beliefs: while being of the hated class that loves the ideas of the unadultered
old testament and classical works from the same time period (not in english).
(Hans Reiser, clearly being of the latter class)
ReiserFS made Linux. And it may have made all of opensource in a way.
Linux was nothing and nowhere before it. I remember those days. It shot up to
the sky on the data centre once the JournalingFS was included. We all switched
to it. It also forced the people who made ext2 to add journaling and make ext3
years later. They wouldn't have done it otherwise.
With Linux's rise, after ReiserFS was added; everything else rose too.
But Hans Reiser is treated like shit now.
He is not respected for his work.
Same with every other "old" C programmer.
They're all kicked out of their own projects. Taken over by entryists.
Everything degraded, regressed, and slowed down.
The type of men who were attracted to working on these engineering projects
don't bother working collectivly anymore: they will not work for FREE under
speech codes: or under others ruling over them "socially". Which is the reason
this has been added to opensource and freesoftware (though RMS resisted it
abit). To discourage engineer participation. It is effective.
There was a time when opensource was the top in security, in resource usage,
and in keeping old machines running, and in new features. JournalingFS,
Pax/GRsecurity hardening, fast execution on ancien regime machines.
We had it all.
And it was taken away.
Socially. When we were targeted by the intelligence agencies, now quite awhile
ago. But I remeber it happening.
Here's the error in windowed mode on OSX, : seems the same to me:
[mvk-info] GPU device:
model: Intel HD Graphics 4000
type: Integrated
vendorID: 0x8086
deviceID: 0x0166
pipelineCacheUUID: 49B97F26-0A0F-0200-0000-000100000000
GPU memory available: 1536 MB
GPU memory used: 0 MB
Metal Shading Language 2.2
supports the following GPU Features:
GPU Family Mac 2
Read-Write Texture Tier 1
[mvk-info] Created VkInstance for Vulkan version 1.0.0, as requested by app,
with the following 2 Vulkan extensions enabled:
VK_KHR_external_memory_capabilities v1
VK_KHR_get_physical_device_properties2 v2
016c:fixme:thread:get_thread_times not implemented on this platform
0144:fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet
0144:fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet
--
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=2082
Zeb Figura <z.figura12(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |z.figura12(a)gmail.com
--- Comment #177 from Zeb Figura <z.figura12(a)gmail.com> ---
(In reply to chaosesqueteam from comment #176)
> Could the entryists that are just going to close and delete this bug be
> gotten rid of? That's how free software is now: every "package" or "app" (we
> used to call them programs and projects) is brigaded by do-nothings padding
> their resume by "resolving" bugs. They just "wont fix" everything and cause
> the project to get worse and worse.
I really don't know where you're getting this from. You have started posting on
this bug tracker less than two weeks ago. No bug you have filed, or even
commented on, has been closed WONTFIX. As someone familiar with many of them, I
don't imagine they will be either, although some of them are very hard and will
probably take a lot of time and resources to fix. The fact that this very bug
is 20 years old but still open should be evidence of this.
Please stop adding noise and complaints to bugs. Apart from everything else
it's a great way to make developers not want to interact with you, or work on
the bugs you are filing.
--
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=2082
--- Comment #176 from chaosesqueteam(a)sogetthis.com ---
Could the entryists that are just going to close and delete this bug be gotten
rid of? That's how free software is now: every "package" or "app" (we used to
call them programs and projects) is brigaded by do-nothings padding their
resume by "resolving" bugs. They just "wont fix" everything and cause the
project to get worse and worse.
Resume: I resolved 1024 bugs!
(bobbles head)
In my linux mint install from 2015 Diablo 1 works fine.
In my Debian install from 2012 Diablo 1 works fine.
In my Devuan install from 2018 Diablo 1 works fine.
In my Debian server from 2003 Diablo 1 works fine.
In OSX from right now, but running on intel: WONT FIX CHUUUDDDDDD
WONT FIX
GT THE FK OUT OF OPENSOURCE
THIS IS ___OUR___ SPACE NOW
ONLY RUST GAMES SUPPORTED
BURN DOWN 16 BIT BECASUE MICROSOFT WOW DOESNT SUPPORT IT
(note: diablo1 is 32 bit)
CHUDDDD
WONT FIX
WONT FIX C PROGRAMS
CHUUUUUUDDDD
CNILE
Etc.
It's all resume padding, and entryism
--
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=2082
chaosesqueteam(a)sogetthis.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |chaosesqueteam(a)sogetthis.co
| |m
--- Comment #174 from chaosesqueteam(a)sogetthis.com ---
I also get this on macosX catalina on 10.12 devel.
Meaning Wine has regressed.
What the hell?
WONT FIX right?
--
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=58542
Bug ID: 58542
Summary: Dual GPU 32-Bit PhysX
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: audioprof2002(a)hotmail.com
Distribution: ---
Batman Arkham Asylum v1.1
32-Bit PhysX has 3 modes:
OFF, Normal, High.
Normal & Off work ok.
PhysX works, but Not High "Dual GPU",
Windows driver allows to force PhysX to a single GPU, Dual GPU or CPU.
Linux driver 470 does Not.
Problem #1. instead of using Dual GPU on Linux or a single GPU,
PhysX falls back to CPU PhysX in Linux.
Problem #2. CPUs are very slow for 32-Bit,
Batman Arkham Asylum PhysX High, requires 1-core 100% CPU load,
gives 15fps on modern CPU´s.
Problem #3.
Nvidia deleted 32-Bit PhysX support in hardware since 2016-Q4,
IF you install a 2017 GPU like P1000, in Windows, Activate/Force PhysX GPU,
Does Not work.
Only work with 2016-Q2 & older GPUs.
im confused where could be the problem...
Linux Nvidia 470 driver?
Wine?
winetricks?
¿how does Wine handle 32-Bit PhysX requests?
block diagram? signal path?
more details here:
https://github.com/juanpc2018/Batman-Arkham-Asylum-Game-of-the-Year-Edition…
--
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=58575
Bug ID: 58575
Summary: Low performance in an old Directx8 Sonic fangame in
wined3d
Product: Wine
Version: 10.11
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: d3d
Assignee: wine-bugs(a)winehq.org
Reporter: user.pecheniok(a)gmail.com
Distribution: ---
This game has a built-in fps counter. After launching it, I was surprised to
find that it ran at only 30 fps in the hub area, while on windows it runs at
60. It is seemingly ok in the gameplay, but fps is often several values short
of 60, and there are also rarer drops to 30 for several seconds. There are no
warnings in the console other than related to directsound. DXVK works at a
locked 60 fps, so that means that it's a problem with wined3d.
Here is the link to the game: https://gamejolt.com/games/sonic3d/28626
--
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=56648
Bug ID: 56648
Summary: Autodesk DWG TrueView fails at installation
Product: Wine
Version: 9.8
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: szatkus(a)gmail.com
Distribution: ---
Installation fails with the fixme: "Could not find dependent assembly
odis.bs.win (1.0.0)"
Turns out the installer creates a new folder (%TEMP%/7z0F0512E4) with another
installer that apparently is invoked next. The program removes it automatically
after crashing, but it could be retrieved by placing `while(1);` next to the
fixme or by using a Windows machine.
There's the Setup.exe file that has the following manifest in its resources:
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level='asInvoker' uiAccess='false' />
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='odis.bs.win' version='1.0.0.0'
processorArchitecture='*' language='*' />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='odis.bs.wx' version='1.0.0.0'
processorArchitecture='*' language='*' />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32'
name='Microsoft.Windows.Common-Controls' version='6.0.0.0'
processorArchitecture='*'
publicKeyToken='6595b64144ccf1df' language='*' />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.Windows.Common-Controls'
version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df'
language='*' />
</dependentAssembly>
</dependency>
</assembly>
From what I gathered this manifest is used to resolve some required dlls files,
but it ultimately fails.
The odis.bs.win is resolved by the following algorithm (a comment from the wine
code):
/* Lookup in <dir>\name.dll
* <dir>\name.manifest
* <dir>\name\name.dll
* <dir>\name\name.manifest
*
* First 'appdir' is used as <dir>, if that failed
* it tries application manifest file path.
*/
The file it's looking for is in ODIS/odis.bs.win/odis.bs.win.manifest, not in
odis.bs.win/odis.bs.win.manifest (name="odis.bs.win"). Where from does Windows
get the ODIS part? Well, there's also a file called "Setup.exe.config" with the
following content:
<configuration>
<windows>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="ODIS"/>
</assemblyBinding>
</windows>
</configuration>
It looks that the program should resolve through <dir>/<privatePath>. I added a
few prints here and there, and it seems that Setup.exe.config is not loaded by
wine at any point.
Moving odis.bs.win and odis.bs.wx to the upper folder fixes the problem,
although the installation still fails after a while.
--
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=57744
Bug ID: 57744
Summary: Custom? 7z self extracting archive for autocad is
broken
Product: Wine
Version: 10.0-rc6
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: francisco278herrera(a)gmail.com
Distribution: ---
Created attachment 77944
--> https://bugs.winehq.org/attachment.cgi?id=77944
dlls that aren't extracted
I tried installing autocad 2025 from the autodesk website
https://www.autodesk.com/products/autocad/overview?term=1-YEAR&tab=subscrip…
the installer at first fails to open. it seems to be a custom? 7z self
extracting archive that is broken so some dlls within it are not extracted and
the installer does not run. i have attached the full terminal output with the
dlls.
so i opened the exe using gnome file roller and copied those dlls to wine's
system32 folder. then the installer runs and gets stuck at 3%, but that is
another bug.
--
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=58505
Bug ID: 58505
Summary: Odd windows management behaviour in later dev versions
Product: Wine
Version: 10.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: kg.hammarlund(a)gmail.com
Distribution: ---
I run a geneaology database program written for windows under wine. It runs
fine on v10.0 (stable) and on dev versions up to 10.4. From v10.5 and upwards,
including v1012, I'm encountering an odd issue.
When opening a search window, this window opens in the background instead of on
top of the main window. I then have to move or resize the main window in order
to highilght the search window and fill in the search data. But this only
happens the first time I open the search window. Next time it opens in the
foreground.
If I untick the box "Allow the window manager to control the windows" in
winecfg > graphics, the search window opens expected. But this solution has its
drawbacks.
--
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=58589
Bug ID: 58589
Summary: The Dark Pictures Anthology: Man of Medan shows a grey
screen in DX12 mode
Product: vkd3d
Version: 1.15
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: regression
Severity: normal
Priority: P2
Component: vkd3d
Assignee: wine-bugs(a)winehq.org
Reporter: andrey.goosev(a)gmail.com
CC: gmascellani(a)codeweavers.com
Regression SHA1: 07b7975d09e8dfbdfc5a9942b4f0c9d054a5cd11
Distribution: ---
After launching the game screen is grey during the first video.
--
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=57414
Bug ID: 57414
Summary: BioShock needs support for 'Generic samplers need to
be lowered'
Product: vkd3d
Version: 1.13
Hardware: x86-64
OS: Linux
Status: NEW
Severity: minor
Priority: P2
Component: hlsl
Assignee: wine-bugs(a)winehq.org
Reporter: andrey.goosev(a)gmail.com
Distribution: ---
Using builtin d3dx9_33 and '-dx9' flag.
098c:err:d3dcompiler:D3DCompile2 Failed to compile shader, vkd3d result -5.
098c:err:d3dcompiler:D3DCompile2 Shader log:
098c:err:d3dcompiler:D3DCompile2 <anonymous>:1:371: E5017: Aborting due to
not yet implemented feature: Generic samplers need to be lowered.
098c:err:d3dcompiler:D3DCompile2
1.13-654-g756b98f0
--
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=56347
Bug ID: 56347
Summary: The Sinking City exits after Click any key to continue
Product: vkd3d
Version: 1.10
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: vkd3d
Assignee: wine-bugs(a)winehq.org
Reporter: andrey.goosev(a)gmail.com
Distribution: ---
After starting new game and loading the game shows 'Click any key to continue'
which results in
0880:err:msvcrt:_wassert (L"1 <= count && count <=
VKD3D_VEC4_SIZE",L"../vkd3d/libs/vkd3d-shader/vkd3d_shader_private.h",1613)
vkd3d-1.10-492-gd9c68ee4
--
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=58578
Bug ID: 58578
Summary: Hygeia Pharmacy: complains that Microsoft ReportViewer
is not installed (unimplemented MsiProvideAssemblyW()
?)
Product: Wine
Version: 10.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: peathot(a)hotmail.com
Distribution: ---
Created attachment 79093
--> http://bugs.winehq.org/attachment.cgi?id=79093
Terminal output of Hygeia Pharmacy running under Wine
Hygeia Pharmacy is a .NET 4 application for pharmacy retail. When the
application starts up, it will check for various shared components, ending up
complaining that Microsoft Report Viewer has to be installed despite already
installed.
Attached is the screenshot of the error. It says, "It's necessary to install an
additional programed named Microsoft Report Viewer"
("มีความจำเป็นต้องติดตั้งโปรแกรมเสริมที่ชื่อว่า Microsoft Report Viewer").
Terminal output reveals 2 interesting FIXME's:
```
0174:fixme:msi:MsiProvideAssemblyW L"Microsoft.ReportViewer.Common,
Version=10.0
.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a,
processorArchitecture=MS
IL", L"C:\\Program Files\\HygeiaPharmacy\\HygeiaPharmacy.exe.config", 0, 0,
10D7
A618, 10D7A614
0174:fixme:msi:MsiProvideAssemblyW L"Microsoft.ReportViewer.Common,
Version=10.0
.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a,
processorArchitecture=MS
IL", (null), 0, 0, 10D7A618, 10D7A614
```
This leads me to believe that the application chokes up because it does not
receive the correct path to this .NET assembly, part of MS ReportViewer 2010.
---
Looking into multiple documents and into Wine itself, I _think_ it would be
relatively simple to implement MsiProvideAssembly[A|W]() using facilities
already implemented in Wine. Bug 58577 plays an important role on this.
I actually would love to get my hands dirty, if not for 2 problems:
1. I don't actually have much time myself.
2. Many years ago, I disassembled a different component of Windows (related to
MDM/management policy) in order to debug my graduating project. I forgot
everything by now, and it's IMHO not related, but combined with 1. I think it's
probably better to stay safe.
(Can I explain some high-level idea? Will I run afoul of 2.?)
A number of MSDN documents that might be useful:
https://learn.microsoft.com/en-us/windows/win32/api/msi/nf-msi-msiprovideas…https://learn.microsoft.com/en-us/windows/win32/msi/assembly-registry-keys-…
Also helpful is a small test program I write myself to exercise
MsiProvideAssemblyW() in the same way as the application (and in a slightly
different way). On Windows 11, this outputs as follow:
```
MsiProvideAssemblyW("Microsoft.ReportViewer.Common, ..." (qualified)) returns 0
Returned path (119):
C:\WINDOWS\assembly\GAC_MSIL\Microsoft.ReportViewer.Common\10.0.0.0__b03f5f7f11d50a3a\Microsoft.ReportViewer.Common.dll
MsiProvideAssemblyW("Microsoft.ReportViewer.Common" (unqualified)) returns 0
Returned path (119):
C:\WINDOWS\assembly\GAC_MSIL\Microsoft.ReportViewer.Common\10.0.0.0__b03f5f7f11d50a3a\Microsoft.ReportViewer.Common.dll
```
On Wine, it outputs (excluding Wine's output itself):
```
MsiProvideAssemblyW("Microsoft.ReportViewer.Common, ..." (qualified)) returns
120
MsiProvideAssemblyW("Microsoft.ReportViewer.Common" (unqualified)) returns 120
```
---
Following is the way I run Hygeia Pharmacy.
Hygeia Pharmacy is a relatively complex application and requires the full .NET
installation (Mono is not enough). The following commands recreate the
environment from scratch:
```
export WINEARCH=win32
export WINEPREFIX=/a/new/prefix
winetricks dotnet48 jet40 mdac28
wine ReportViewer.exe # sha256sum:
e8ff182e202b321ac2b9245ee20c4eb659008ffb2a34cdbd3486f9da3d4c3e06
wine hygeia_trial_install.2.6.28.1.exe # sha256sum:
380085defb0af240f144d603da70d09a76c940a27a65953a9fbe3668c321b4e2
wine "C:\\\\users\\\\Public\\\\Desktop\\\\Hygeia Pharmacy.lnk"
&>hygeia_pharmacy_wine_output.txt
```
---
The (trial) version can be obtained from
https://www.hygeia-pharmacy.com/trial/. However, it requires a (free)
registration, and the website is entirely in Thai with no English version.
In order to (try to) help you with the registration, the registration page at
https://www.hygeia-pharmacy.com/register/ requires the followed:
1. A chosen username ("Hygeia ID")
2. A chosen password.
3. Your full name
4. Your email.
5. A math captcha (input the equation's answer).
I can't remember if there's an email verification after that step or not,
because it's been a long time since I registered myself.
Once logged in, https://www.hygeia-pharmacy.com/trial/ will show a big blue
button for downloading the trial version. The same page will also be a smaller
link for "MS Report Viewer" which is hosted by Hygeia Pharmacy themselves (if
you prefer an MS link, see the end of bug 58577).
--
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=58588
Bug ID: 58588
Summary: Tokens Acquired from WTSQueryUserToken do not set the
session id for the token correctly
Product: Wine
Version: 10.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wtsapi32
Assignee: wine-bugs(a)winehq.org
Reporter: katharina(a)hacked.xyz
Distribution: ---
A service running under NTAUTHORITY\SYSTEM may use the Windows Terminal Server
API to resolve user sessions. This is also works on non-terminalservers, that
is, normal computers where only one simoultaneous session is allowed.
My best guess is that Windows internally treats all sessions as terminal
service sessions, so this API becomes canon.
If a service wants to then spawn a process attached to this user's session, so
that the spawned process is able to open a window showing in the user's
session, it may use CreateProcessAsUserW to do this, and supply a token to a
users's Windows session.
The general principle is for example documented in this stackoverflow question:
https://stackoverflow.com/questions/3128017/launching-a-process-in-user-s-s…
A real-world user of this mechanism is the Dassault 3DEXPERIENCE Launcher,
which is unfortunately not available without purchase.
The actual source of the token is not terribly important; the code I debugged
uses WTSEnumerateSessions in conjunction with WTSQueryUserToken. The latter
should return a token that has it's session ID set to the current users session
ID; most likely 1.
A reproducer for this bug is available here:
https://gitlab.winehq.org/hackathi/wtsqueryusertoken-bug
--
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=58587
Bug ID: 58587
Summary: Bioshock 1.0 demo crashes during HLSL shader
compilation
Product: vkd3d
Version: 1.16
Hardware: x86-64
URL: http://us.download.nvidia.com/downloads/nZone/demos/nz
d_BioShockPC.zip
OS: Linux
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: hlsl
Assignee: wine-bugs(a)winehq.org
Reporter: gijsvrm(a)gmail.com
Distribution: ---
Created attachment 79113
--> http://bugs.winehq.org/attachment.cgi?id=79113
log
vkd3d:01a0:warn:vkd3d_shader_vwarning <anonymous>:200:7: W5300: Implicit
truncation of vector type.
vkd3d:01a0:warn:vkd3d_shader_vwarning <anonymous>:574:27: W5300: Implicit
truncation of vector type.
vkd3d:01a0:warn:vkd3d_shader_verror <anonymous>:717:3: E5013: Invalid semantic
'SV_ClipDistance'.
vkd3d:01a0:warn:vsir_parse Failed to parse shader.
vkd3d:01a0:warn:vkd3d_shader_vwarning <anonymous>:200:7: W5300: Implicit
truncation of vector type.
vkd3d:01a0:warn:vkd3d_shader_vwarning <anonymous>:574:27: W5300: Implicit
truncation of vector type.
vkd3d:01a0:warn:vkd3d_shader_vwarning <anonymous>:627:21: W5300: Implicit
truncation of vector type.
vkd3d:01a0:warn:vkd3d_shader_vwarning <anonymous>:639:55: W5300: Implicit
truncation of vector type.
vkd3d:01a0:warn:vkd3d_shader_verror <anonymous>:627:21: E5017: Aborting due to
not yet implemented feature: SM4 half3 multiplication expression.
vkd3d:01a0:warn:vkd3d_shader_verror <anonymous>:639:55: E5017: Aborting due to
not yet implemented feature: SM4 half3 multiplication expression.
vkd3d:01a0:warn:vkd3d_shader_verror <anonymous>:639:55: E5017: Aborting due to
not yet implemented feature: SM4 half3 addition expression.
vkd3d:01a0:warn:vkd3d_shader_verror <anonymous>:235:16: E5017: Aborting due to
not yet implemented feature: SM4 half3 multiplication expression.
vkd3d:01a0:warn:vsir_parse Failed to parse shader.
I have attached a full log.
--
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=58527
Bug ID: 58527
Summary: autocad electrical 2026 error in wxwidgets
Product: Wine
Version: 10.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: grandrodri3(a)gmail.com
Distribution: ---
Created attachment 79001
--> http://bugs.winehq.org/attachment.cgi?id=79001
autocad architecture error in wxwidgets
Hey, hello guys, how are you?
Well, I'm adding a new application to the Wine database. This is an AutoCAD
application developed by Autodesk, specifically for electrical plans
(specifically, electrical panel installations in homes). So, I'm reporting the
error the installer gives me to see if anything can be done. The error I'm
getting, by the way, was loaded with the following DLLs installed:
vcrun2012 vcrun2022 dotnetcore3 dotnet8
I get an error in the DLLs for the Windows implementation of wxwidgets. I've
tried installing wxwidgets from their official website, but nothing. AutoCAD
doesn't go beyond the terminal (that is, the installer doesn't display).
official download website:
https://www.autodesk.com/es/products/autocad/included-toolsets/autocad-elec…
I'll pass what I get in the terminal.
Could you please check it?
Best regards.
--
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=58583
Bug ID: 58583
Summary: msvcp140: Multiple modern applications using C++
Concurrency crash in CONCRT140.dll on startup
Product: Wine
Version: 10.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: msvcp
Assignee: wine-bugs(a)winehq.org
Reporter: waser(a)waser.tech
Distribution: ---
Created attachment 79107
--> http://bugs.winehq.org/attachment.cgi?id=79107
The game's own crash log from its `_appdata_ixray_/logs` directory.
This report details a consistent, immediate startup crash in `CONCRT140.dll`
affecting modern S.T.A.L.K.E.R. engine forks. These engines are based on the
open-source **Open X-Ray 1.6**, which itself works flawlessly under Wine.
The crash only appears in these newer, more advanced forks which leverage the
MSVC concurrency runtime for performance. This strongly indicates the issue
lies within Wine's implementation of these APIs, not a bug in the engines
themselves. This is effectively a regression, as the baseline engine works
while the newer, concurrency-enabled versions do not.
**Existing Related Bugs:**
This issue appears to be a new, highly reproducible test case for known
problems in Wine's concurrency support. We are filing this as a new report due
to the unique test case and the specific failure point (constructor vs.
destructor), but it is likely caused by the same underlying issues as:
- **Bug 52899:** Notes that `CONCRT140.dll` requires `CreateEventExW` from
`kernel32`. This is the most likely root cause.
- **Bug 41749:** Shows a crash in the destructor for
`Concurrency::details::_TaskCollection`. Our crash occurs in the *constructor*
of this same object, demonstrating a different failing code path.
Our report provides two clear methods to reproduce this crash, including one
that is fully free and requires no commercial software.
---
### **Primary Reproduction Steps (IX-Ray on S.T.A.L.K.E.R.: Call of Pripyat)**
*(Steps 1-5 as in previous draft)*
6. **Run the Game with Debug Logging:** Launch the game using its main
executable with full debug channels enabled.
```bash
WINEDEBUG=+all wine Stalker-COP.exe &> stalker_cop_crash_all.log
WINEDEBUG=+seh,+loaddll wine Stalker-COP.exe &> stalker_cop_crash_seh.log
```
7. **Result:** The process will crash immediately. The game's own crash log
(in `_appdata_ixray_/logs`) and the attached Wine debug logs will show a fatal
error in `CONCRT140.dll`.
---
### **Alternative Reproduction Steps (AOEngine on S.T.A.L.K.E.R. Anomaly)**
*(As in previous draft, but with the same logging commands)*
---
**Expected Behavior:**
The game launcher should appear, and the game should launch to the main menu
successfully, as it does on Windows and as the baseline Open X-Ray 1.6 engine
does under Wine.
**Logs:**
Three files will be attached for the primary reproduction case:
1. `stalker_cop_crash_seh.log`: A small log with `+seh,+loaddll` for quick
initial review.
2. `stalker_cop_crash_all.log.bz2`: The complete `+all` debug log, compressed
with bzip2 due to its large size.
3. `ixray-2025.08.10-02.37.21-waser.log`: The game's own crash log from its
`_appdata_ixray_/logs` directory.
**References:**
- **IX-Ray GitHub (Open Source Engine):**
https://github.com/ixray-team/ixray-1.6-stcop
- **GE-Proton Issue #197 (Full History):**
https://github.com/GloriousEggroll/proton-ge-custom/issues/197
--
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=44966
Bug ID: 44966
Summary: [ER: The Game] A style error occurred while verifying
the reading of the license agreement.
Product: WineHQ Apps Database
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: appdb-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ilya(a)ilin.pp.ua
Distribution: ---
Created attachment 61088
--> https://bugs.winehq.org/attachment.cgi?id=61088
Screenshot
When installing the game, the possibility of accepting the license agreement is
conceived only if it is fully read (textarea should scroll to the bottom).
But in wine it does not work.
wine 3.5 openSUSE Tumbleweed
Game download: (registry don't need)
https://firedrop.com/4bfe735821e6bfcb or
http://www.theisozone.com/downloads/pc/windows-games/er---the-game (Black
Download button)
Patches: https://www.gamewatcher.com/games/er/downloads
0030:err:ole:TLB_ReadTypeLib Loading of typelib L"C:\\Program Files
(x86)\\Common Files\\InstallShield\\Professional\\RunTime\\IsProBE.tlb" failed
with error 2
0030:fixme:ntdll:NtLockFile I/O completion on lock not implemented yet
0030:fixme:apphelp:ApphelpCheckInstallShieldPackage stub: 0x33dd3c
L"M:\\data1.hdr"
0030:err:richedit:ReadStyleSheet skipping optional destination
0030:err:richedit:ReadStyleSheet skipping optional destination
0030:err:richedit:ReadStyleSheet skipping optional destination
--
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=58490
Bug ID: 58490
Summary: MusicBee: tab dragging still does not work
Product: Wine
Version: 10.11
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: v_winebugs(a)outlook.com
Distribution: ---
Bug 52078 was solved thanks to the drag and drop helpers being stubbed, however
WINE still does not allow for tab dragging with MusicBee, so I'm adding it as a
separate bug report.
How to reproduce:
On MusicBee, attempt to drag a tab.
Expected behaviour:
MusicBee should allow me to drag the tab and drop it to move it.
Actual behaviour:
A prohibited cursor shows up and the tab is unable to be dragged.
Tested on WINE Staging 10.11 on Arch Linux
--
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=58580
Bug ID: 58580
Summary: macOS clang: -msabi=ms unrecognized option... causes
x86_64-unix/*.a files to be missing. Cannot winegcc
cannot link agains libadvapi32 et al
Product: Wine
Version: 10.0
Hardware: x86-64
OS: MacOS
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winelib
Assignee: wine-bugs(a)winehq.org
Reporter: matteo.ceruti(a)gmail.com
Created attachment 79102
--> http://bugs.winehq.org/attachment.cgi?id=79102
the patch for the configure-script that works for me
I had first reported this to macports but I think you should have a look at it
https://trac.macports.org/ticket/72792
Expected Behavior:
I like to continue to use winegcc and wineg++ on macOS x86_64 to compile
winelibs. In fact it worked with wine 9.0.
Actual Behavior:
winegcc says it cannot link against advapi32 and others and infact the files
such as libadvapi32.a are not in lib/x86_64-unix/ anymore.
I think this might be the case since this change:
https://github.com/wine-mirror/wine/commit/84d8a24af71d#diff-49473dca262eeab3b4a43002adb08b4db31020d190caaad1594b47f1d5daa810L1969
"Disable non-PE import libraries if compiler support is missing."
The -mabi-ms check is now done even if $PE_ARCHS exist which in my
understanding means we're crosscompiling PE code. The macport compiles with
clang and uses minGW to compile the PE code. But clang does not recognize and
no longer ignores the -mabi=ms option and in that case the configure-script now
sets DLLEXT from its initial value ".so" to "" which seems to cause the *.a
archive files to not being created/installed.
I've patched the configure-script so that DLLEXT is only set to "" in case
$PE_ARCHS is empty analogous to the fact that in that -mabi=ms not being
recognized is not reported as an error.
And I can create winelibs .exe.so and .dll.so just fine and load them from a
client *.exe.
I'd like to still use winegcc and wineg++ and the winelib feature on macOS. Is
this no longer possible? I guess linux using clang might experience the same.
This is my the patch that works for me on wine 10.12 (It's also attached):
https://github.com/matatata/macports-ports/blob/ff459f21995e6b6fceeacd51cea…
I'd appreaciate if you could take a look and clarify.
--
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=58581
Bug ID: 58581
Summary: Nirsoft siteshooter only produces "black" files
Product: Wine
Version: 10.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: kyle.kcsoftwares(a)gmail.com
Distribution: ---
Install Nirsoft Siteshooter 1.42 (https://www.nirsoft.net/utils/siteshoter.zip)
Use http://www.google.com as URL and "test.png" on desktop as local file and
run a screenshot
test.png is only a black png and no error is raised.
--
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.