January 2018 - Wine-Bugs - list.winehq.org

[Bug 38152] PureBasic IDE crashes when launching online help ("F1" key)

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=38152 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #9 from Nikolay Sivov <bunglehead(a)gmail.com> --- (In reply to niffo from comment #8) > Was fixed for PureBasic x86 on wine x86 1.7.x but now (or still?) crashes > with PureBasic x64 on wine64. > (tested With PureBasic 5.61 x64) Please open a new bug for that. -- 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.

Jan. 10, 2018

[Bug 44329] Listview does not reset returned state mask for subitems

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=44329 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Listview custom draw in |Listview does not reset |report mode uses wrong |returned state mask for |state of LV_ITEM using |subitems |LVIS_STATEIMAGEMASK | -- 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.

Jan. 10, 2018

[Bug 44329] Listview custom draw in report mode uses wrong state of LV_ITEM using LVIS_STATEIMAGEMASK

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=44329 --- Comment #7 from Nikolay Sivov <bunglehead(a)gmail.com> --- The problem is not that wrong state is returned, but actually state field is not touched at all when requesting subitem data. I'll send a fix for that after code freeze. P.S. running your test exe is problematic, it needs mfc140, but after installing vcrun2015, it still crashes because of some ucrtbase vs api-ms-* forwards. If possible please rebuild it with older Visual Studio. -- 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.

Jan. 10, 2018

[Bug 44335] New: Blizzard App crashes at start because of d3d11.dll

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=44335 Bug ID: 44335 Summary: Blizzard App crashes at start because of d3d11.dll Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: abel.thorne(a)free.fr Distribution: --- Just got an update of Battle.net/Blizzard App (which was working perfectly). Now it doesn't start anymore and triggers the following errors: err:module:import_dll Library d3d11.dll (which is needed by L"C:\\Program Files (x86)\\Blizzard App\\Battle.net.9737\\libcef.dll") not found err:module:import_dll Library libcef.dll (which is needed by L"C:\\Program Files (x86)\\Blizzard App\\Battle.net.9737\\battle.net.dll") not found fixme:ver:GetCurrentPackageId (0x33fda4 (nil)): stub Using Wine Staging 2.21 if that matters. -- 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.

Jan. 10, 2018

[Bug 44334] New: 'start /W "" notepad' does not wait as on native.

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=44334 Bug ID: 44334 Summary: 'start /W "" notepad' does not wait as on native. Product: Wine Version: 3.0-rc5 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: cmd Assignee: wine-bugs(a)winehq.org Reporter: bernhardu(a)mailbox.org Distribution: --- Created attachment 60210 --> https://bugs.winehq.org/attachment.cgi?id=60210 cmd: Avoid having first parameter to start.exe ignored. Tried to have a look into #44236. There a batch script is executed but the start commands did not wait until the started processes did end. Example line: --- start /W " " "%SFDIR%automesh" wr2300 --- As far as I see this is because when WCMD_start encounters an title parameter, it removes the executable from the cmdline parameter to CreateProcessW. --- start /W "" notepad 002f:trace:process:create_process_impl app L"C:\\windows\\command\\start.exe" cmdline L"/W \"\\\"\\\"\" notepad" --- This get not recognized much, because usually the title is the first parameter and is therefore ignored by start.exe. But start.exe get executed because it is also in the file parameter to CreateProcessW. Attached is a patch that tries to maintain the executable as first parameter in the cmdline parameter to CreateProcessW. -- 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.

Jan. 10, 2018

[Bug 38152] PureBasic IDE crashes when launching online help ("F1" key)

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=38152 niffo(a)free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|x86 |x86-64 Status|CLOSED |UNCONFIRMED Resolution|FIXED |--- Version|1.6.2 |2.22 --- Comment #8 from niffo(a)free.fr --- Was fixed for PureBasic x86 on wine x86 1.7.x but now (or still?) crashes with PureBasic x64 on wine64. (tested With PureBasic 5.61 x64) -- 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.

Jan. 10, 2018

[Bug 43590] Rise of Nations Thrones & Patriots weird graphics

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #8 from pe.we.psi(a)gmail.com --- (In reply to Matteo Bruni from comment #7) > I spent some time on this and I think I know what's going on. Chatty log of > the debugging process follows, feel free to skip to the end. > > I'll start by mentioning that I tested the game on Windows and it does work > fine there. I couldn't find anything wrong from the logs + OpenGL apitrace > so I decided to take a d3d8 apitrace on Windows and figure out which draw > breaks on Wine. To my surprise, replaying the d3d8 trace on Windows showed > pretty much the same artifacts as Wine. That suggests either there is > something drawing "out of channel" or apitrace somehow missed out on > something, exactly as Wine. > > Back to Linux, I see no evidence of the former. I then go back staring at > the draw I found the most suspicious. Essentially the game draws all the > tiles of the map normally, then this draw "darkens" some of the tiles by > blending in some semitransparent black triangles. In the log that is: > > 0009:trace:d3d8:d3d8_device_DrawIndexedPrimitive iface 0x130468, > primitive_type 0x4, min_vertex_idx 0, vertex_count 2150, start_idx 0, > primitive_count 2752. > > Hmm, that seems a lot of triangles to draw so few black spots (after you > move the camera around a bit, at least). Checking the contents of the index > and vertex buffers doesn't show anything clearly wrong. But then I happen to > notice how the vertex buffer is updated: > > 0009:trace:d3d:wined3d_buffer_map buffer 0x57f00b0, offset 0, size 5000, > data 0x32dde0, flags 0. > > For the records the vertex stride is 20 bytes. That means only 250 vertices > are updated. Which would be all fine and good, except that's how the buffer > is mapped ALL the times, including the first time. > > It turns out that the game updates the buffer outside of the mapped area. > That apparently works on Windows (my guess is that the whole buffer is > mapped regardless of the size - it's a DYNAMIC, WRITEONLY buffer FWIW) while > in current wined3d that works only for the initial buffer upload but > obviously fails for subsequent updates. > Hacking the buffer map to e.g. replace size == 5000 with 100000 does avoid > the bug. I initially tried to hack a DISCARD flag into the map but that > didn't quite work right, which I guess means that the game doesn't overwrite > the entire (used portion of the) buffer on each update. > > It would be interesting to know if there are more applications doing the > same. I don't see obvious generic workarounds we can do to fix this. It's > worth mentioning that persistent buffer maps from ARB_buffer_storage could > potentially avoid this bug. Very interesting findings. But it is also true, that RON runs flawlessly in wine with the stable version 2.0 and before (also at least with 2.01). The problem (weird rendering) first ocurred with development version (wine 2.1) and persists until the actual development versions. Also the newer revised stable version 2.03 now seems to be affected). -- 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.

Jan. 10, 2018

[Bug 43728] Magic: The Gathering Online intensive CPU usage when idle

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=43728 Anton Romanov <theli.ua(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60157|0 |1 is obsolete| | --- Comment #21 from Anton Romanov <theli.ua(a)gmail.com> --- Created attachment 60209 --> https://bugs.winehq.org/attachment.cgi?id=60209 fix v2 Proposed fix Will try to submit along with test once I clean it up in a day or two. -- 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.

Jan. 10, 2018

[Bug 43728] Magic: The Gathering Online intensive CPU usage when idle

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=43728 --- Comment #20 from Anton Romanov <theli.ua(a)gmail.com> --- Created attachment 60208 --> https://bugs.winehq.org/attachment.cgi?id=60208 test patch So I was trying to come up with the patch that would show this behaviour. As seen windows doesn't pump messages either, however it does PEEK at messages so that they will not trigger MsgWaitForMultipleObjects again, if our CoWaitForMultipleHandles would also do that then it will not be an issue as CoWaitForMultipleHandles will not look at those messages in the queue again. This change to test makes test fail on wine but it succeeds on windows. -- 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.

Jan. 10, 2018

[Bug 29582] Star Wars Battlefront (I and II) "Loading" screen very slow.

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=29582 --- Comment #42 from Maxim Stewart <gamer1119(a)gmail.com> --- (In reply to Daniel Santos from comment #41) > Well, graphics and sound alone won't do it for me -- it's like coca-cola > where you get a lot of pop, zip, fiz, but no substance or bang. It's just > so sad they'll put all that work and talent into inventing new ways of > making amazing graphics and then attach a crap game to it. It's like > painting a masterpiece only to cut it out of the frame, rub a glue stick on > the back and sticking it to the trunk of a beat-up 1978 monte carlo with > fading paint and a busted muffler. I mean, it's their masterpiece and they > can do whatever they want with it, but damn! > > Anyway, I tested it it's working great with SWBF2. The computer I tested on > is old (quad-core Phenom) and with the patch disabled it takes 87.5 seconds > to load vs 12.3 seconds with. I only tested an old retail DVD version and > not the recently patched one from steam, but I doubt much has changed > structurally in the program its self. > > I don't think this patch will be in PoL or Wine anytime soon because it's a > *massive* change with around 8k new lines of code (not counting 2k lines of > debugging and verification code) and altering a lot of how the wineserver > works (which is at the core of Wine). My best hope is to have it in > wine-staging within a month or two, but it still needs a lot of cleanup. > However, I presume that something like the little hack patch could end up in > PoL -- I haven't used it much and I'm not sure how their "connectors" work. > > As far as integrating it with PoL, I don't know how you can do that. To my > knowledge, you would just have to build it. There is a guide here: > https://wiki.winehq.org/Building_Wine, but it's not very easy for the > uninitiated. :o Then again, after you do it the first time it will get > easier the next time you need to build it for some reason. The only thing > you would do differently is get the sources from my github account and > checkout the "hybrid-sync" branch. > > As an afterthought, I have not yet tested building only 32-bit (with a > 32-bit server), but that will be fine as long as I didn't break something. :D You had me hee-hawing at a master piece being cut out and glued to the car. I just imagined The Scream by Munch being cut out by a kid who's 5 and grinning stupidly with glue stick glue in his mouth. XD Now, I don't think that the Steam version changed much either even after the updates. Still, it's worth my asking you since you coded the patch and know more about what's going on with it. Anyway, I compiled the wine version in 32bit given that when I ran the ./configure command it complained about not having some 32bit dev-libs needed. I hadn't thought to pass an argument to the command to prep it for 64bit instead. My machine is 64bit but I assumed that you had made the version 32bit for some reason. Shame on me for being presumptuous and on top of that building the version in a VirtualBox. <sigh> Anyway, I looked through the info for PlayOnLinux and I did find where they're storing their Wine versions. Their layout is quite different from the compile directory but I assume it follows standard layouts that a normal Wine install would have. I bet you I could just run the Steam game from cli and use the command you gave instead of going through PoL itself. Here is what I did for compile in VirtualBox running 32bit Ubuntu 16.04 LTS 1. Make sure to add or uncomment the sources URIs in /etc/apt/sources.list 2. sudo apt-get update 3. sudo apt-get build-dep wine 4. git clone https://github.com/daniel-santos/wine 5. git checkout hybrid-sync 6. cd /the/location/of/wineBuildDir/ 7. ./configure // Add a switch to build in 64 bit else just leave as is. 8. make 9. make install // Optional since we can run from the build dir. TO-DO 10. STAGING_SHARED_MEMORY=1 STAGING_SHM_SYNC=1 WINEPREFIX=<your_prefix> wine GameData/BattlefrontII.exe First, did I do it wrong? Second, if no, then I need to test the compiled version and get back to you. But, from the looks of it, nothing went wrong during the compiling of your Wine version in 32bit. Now, I gotta do it for the 64bit version. Quick confirmation, the WINEPREFIX is the location path for my virtual drive containing my Steam and game, yes? So, it'd be the master folder of the drive folder called drive_c or is it drive_c itself? -- 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.

Jan. 10, 2018