https://bugs.winehq.org/show_bug.cgi?id=39113
Bug ID: 39113
Summary: SimplePC_SC.exe does not work
Product: Wine
Version: unspecified
Hardware: x86
URL: http://downloads.acs.com.hk/utility-tools/en/TOL-PCSC.
zip
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winscard
Assignee: wine-bugs(a)winehq.org
Reporter: vincent.hardy.be(a)gmail.com
Distribution: ---
Created attachment 52115
--> https://bugs.winehq.org/attachment.cgi?id=52115
screenshot
SimplePC_SC is a programme that tests easily the basic functions of winscard
with any smartcard.
I file this bug in the hope that a friendly developer starts a real
implementation of winscard.
--
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=43224
Bug ID: 43224
Summary: Freelist scan can result in O(n) time when allocating
Product: Wine
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: ranma42(a)gmail.com
Distribution: ---
Created attachment 58517
--> https://bugs.winehq.org/attachment.cgi?id=58517
Micro-benchmark that shows the degenerate behaviour
The heap implementation in ntdll can be very inefficient for some allocation
patterns.
Specifically, it is possible that a freelist contains thousands of entries of a
given size and it is scanned while looking for a bigger entry, that will not
fit in any of those.
This is demonstrated by the attached program. It accepts a size as an argument
and will allocate 1000000 elements of that size, deallocate half of them (the
"even" ones), then allocate 1000 elements that are just one bit bigger.
For most sizes the program terminates in milliseconds, but in my environment it
takes several seconds for sizes 16, 32, 48, 64, 80, 88, 96, 112, 120, 128.
A possible workaround (that I had implemented in the past, for short-lived
applications) is to allocate from a freelist whose entries are all at least as
big as the block that is being allocated, but that can cause inefficient memory
usage.
I noticed that wine includes an implementation of a red-black tree.
Would it make sense to organise the free entries as lists in such a tree?
That should ensure O(log N) in the worst case.
If performance is a concern, it might be possible to use "direct" freelists for
small sizes (ensuring that all of the alignment-compatible sizes are covered)
and use a tree for bigger sizes.
I am willing to work on this, but I need some directions on what is the best
path forward (namely, if we should prefer the memory-inefficient but simpler
approach of just allocating from "bigger" freelists or if the tree approach is
the desired one).
The bug https://bugs.winehq.org/show_bug.cgi?id=37773 might be related.
--
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=37146
Bug ID: 37146
Summary: Untis 2015: Crashes while starting
Product: Wine
Version: 1.6.2
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: schutthuffe(a)web.de
Created attachment 49371
--> https://bugs.winehq.org/attachment.cgi?id=49371
Report generated by wine
Installing Untis 2015 seemed to work. Trying to start the program, the
following message popped up: "Im Programm untis.exe traten schwerwiegende
Fehler auf und es muss beendet werden. Wir entschuldigen uns für die
Unannehmlichkeit." The following report is 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.
http://bugs.winehq.org/show_bug.cgi?id=24256
Summary: 3D Sexvilla 2: extremely long loading times
Product: Wine
Version: 1.2
Platform: x86
URL: http://www.3d-sexgames.com/
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: mailme667(a)yahoo.co.uk
Loading time makes the game unusable (version 2.093). I just watched the
loading screen for half an hour. But I know it works, because I tried starting
the game, turning the monitor off, having dinner and see the game running when
I came back a long time later.
Clean .wine tested. Other users in appdb have reported the same problem, it's
not just me.
Bug is tested to be present on wine 1.2 and 1.3.1. sysprof makes it clear ntdll
is consuming nearly all the time.
Using wine 1.2 the following is seen repeating over and over with winedebug
during loading:
002e:Call KERNEL32.GetTickCount() ret=7da7655d
002e:Ret KERNEL32.GetTickCount() retval=00032601 ret=7da7655d
002e:Call KERNEL32.GetTickCount() ret=7e7997bb
002e:Ret KERNEL32.GetTickCount() retval=00032601 ret=7e7997bb
002e:Call KERNEL32.GetTickCount() ret=7e7997bb
002e:Ret KERNEL32.GetTickCount() retval=00032607 ret=7e7997bb
002e:Call KERNEL32.GetTickCount() ret=7da76415
002e:Ret KERNEL32.GetTickCount() retval=00032607 ret=7da76415
002e:Call ntdll.RtlAcquireResourceShared(00187fa4,00000001) ret=7da76541
002e:Ret ntdll.RtlAcquireResourceShared() retval=00000001 ret=7da76541
002e:Call ntdll.RtlReleaseResource(00187fa4) ret=7da76555
002e:Ret ntdll.RtlReleaseResource() retval=00000000 ret=7da76555
I got the following from wine-dbg also using 1.2:
Wine-dbg>bt 0x0000002e
Backtrace:
=>0 0xb7705430 (0x04e0e9d8)
1 0x7e78ea4a TIME_MMSysTimeThread+0x329(arg=0x4e0ea34)
[/build/buildd/wine1.2-1.2/dlls/winmm/time.c:218] in winmm (0x04e0ea68)
2 0x7e78ea4a TIME_MMSysTimeThread+0x329(arg=0x7e770000)
[/build/buildd/wine1.2-1.2/dlls/winmm/time.c:218] in winmm (0x04e0ea78)
3 0x7bc6f8f0 call_thread_func+0xb() in ntdll (0x04e0eb48)
4 0x7bc6fac0 call_thread_entry_point+0x6f(entry=0x7e78e720, arg=0x7e770000)
[/build/buildd/wine1.2-1.2/dlls/ntdll/signal_i386.c:2473] in ntdll (0x04e0f398)
5 0x7bc780b5 start_thread+0xf4(info=0x7ff9cfb8)
[/build/buildd/wine1.2-1.2/dlls/ntdll/thread.c:399] in ntdll (0x04e0f498)
6 0xb757780e start_thread+0xbd() in libpthread.so.0 (0x00000000)
I hope I've provided enough information.
--
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=34011
Bug #: 34011
Summary: Path of Exile stutters constantly
Product: Wine
Version: 1.6-rc4
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: michael.blumenkrantz(a)gmail.com
Classification: Unclassified
When playing the game, any time a new resource is loaded from disk, the game
freezes completely for some time while it waits for the load. Given that the
game is constantly loading things from disk, it makes the game nearly
unplayable in many cases.
--
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=45882
Bug ID: 45882
Summary: (Overwatch, several source games) Raw Mouse input not
working
Product: Wine
Version: 3.16
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: florian98.rg(a)gmail.com
Distribution: ---
Playing Overwatch I've noticed that the game still uses mouse pointer speed
even though on Windows it uses Raw Mouse input exclusively.
I've tried this on any branch of Wine (staging, esync, whatsoever) and the
problem still persists. This also happens in Valve games where you can enable
Raw Mouse Input, e.g. Team Fortress 2 etc.
This does not happen with the native ports of said games that use SDL to get
mouse input.
I already disabled any mouse acceleration in GNOME whatsoever (using the "Flat"
Profile), however the problem persists.
Is it possible to rewrite Wine to get Mouse input via SDL2 instead? That would
help pave way for Wayland etc.
Thanks
--
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=29096
Bug #: 29096
Summary: Phoenix (steam file extractor) z-order of popup is
wrong
Product: Wine
Version: 1.3.32
Platform: x86
URL: http://stat1cv01d.com/load/phoenix_1_5_beta_8/1-1-0-13
OS/Version: Linux
Status: NEW
Keywords: download
Severity: trivial
Priority: P2
Component: user32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: austinenglish(a)gmail.com
Classification: Unclassified
80056a42f6b0e96426751497a8c322de0cdf0602 Phoenix_15beta8.rar
After
http://source.winehq.org/git/wine.git/commitdiff/2429ef905c46aec91465ac187c…,
the program runs. It pops up a dialog on first run, asking if you want to put a
shortcut on the desktop. The dialog is behind a splash screen, so you have to
alt+move to get to it.
A virtual desktop also works around it.
--
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=38642
Bug ID: 38642
Summary: Geometry Wars crashes when changing screen resolution
Product: Wine
Version: 1.7.43
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: directx-d3dx9
Assignee: wine-bugs(a)winehq.org
Reporter: ben(a)xnode.org
Distribution: ---
The game opens and works fine, but if you try and change the fullscreen
resolution, the game crashes out with a Wine page-fault pop-up message:
Unhandled exception: page fault on read access to 0x00000004 in 32-bit code
(0x00429ec7).
Unfortunately I cannot get more info on this right now as I've switched to
Wine-Staging to test some other things.
--
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=29028
Bug #: 29028
Summary: Starcraft crashes on exit
Product: Wine
Version: 1.3.31
Platform: x86
OS/Version: FreeBSD
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: amasterov(a)gmail.com
Classification: Unclassified
After upgrading wine to 1.3.31 Starcraft crashes on exit.
wine 1.3.30 has not this problem.
After choosing exit in game menu I get black screen in 640x480 resolution (I
switch to nvidia-settings with Alt-Tab and set up correct resolution after
this). In console there are this lines:
fixme:advapi:SetSecurityInfo stub
fixme:win:EnumDisplayDevicesW ((null),0,0x33f3d8,0x00000000), stub!
err:seh:setup_exception_record stack overflow 844 bytes in thread 0024 eip
0041efcc esp 00240fe4 stack 0x240000-0x241000-0x340000
err:ntdll:RtlpWaitForCriticalSection section 0x62385d40 "time.c:
TIME_tz_section" wait timed out in thread 0027, blocked by 0024, retrying (60
sec)
err:seh:raise_exception Unhandled exception code c0000194 flags 0 addr
0x6231354f
I've tried regression testing with git bisect and get this result:
496b438ede825fc00daac7a5869e045ae583cec9 is the first bad commit
commit 496b438ede825fc00daac7a5869e045ae583cec9
Author: Stefan Dösinger <stefan(a)codeweavers.com>
Date: Tue Sep 27 09:31:59 2011 -0500
wined3d: Remove d3d8/9 palette support.
:040000 040000 8b95a8e0e4e7524170ba43bc2ffe369359b9811d
7c427ec5a0816aa5da25718cee9c70e0d3605214 M dlls
:040000 040000 a6ee1c817b1f21634ddad86780fad5cfe9c4fb29
fe57de377c4cf96d0f48c4560d0db321b7b28e91 M include
There was slightly different errors on the screen during testing, but I did
"git bisect bad" on every crash on exit.
With what WINEDEBUG flags should I run wine to provide any additional
information about this issue?
--
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.