http://bugs.winehq.org/show_bug.cgi?id=17006
Summary: setlocale to "en_us.UTF8" succeeds under wine, fails
with native, causes knock-on failures
Product: Wine
Version: 1.1.13
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: msvcrt
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: lkcl(a)lkcl.net
here's a python program which, when run under wine, succeeds
when using native msvcrt, and fails using native, but for very
odd reasons (attached).
note the setting of locale (equivalent in c to setlocale(LC_TYPE,
"en_US.UTF-8")?
well, with native msvcrt.dll, that fails - the locale doesn't exist.
so, the test is skipped.
but under wine, it proceeds... and then wine fails to do the right things!
in other words, it _does_ identify 0xa0 as a space (true), it _does_
identify 0xc0 as alpha, and a number, and upper.
the next tests, which depend on 0xa0 being _not_ identified as space,
then obviously fail as well.
so the question is: strictly speaking, setlocale("en_US.UTF-8") shouldn't
be going ahead in the first place, but if it does, should these tests
work as expected?
wossgoinon? :)
--
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=29426
Bug #: 29426
Summary: UDF support: VOLUME_GetSuperblockSerial invalid for
some volume types
Product: Wine
Version: unspecified
Platform: All
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: kernel32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: winehq.org(a)mcfang.com
Classification: Unclassified
VOLUME_GetSuperblockSerial returns an incorrect serial for certain UDF volumes.
Volume types affected:
* ISO9660+UDF for all revisions: Serial displays as '0104-0001'
* UDF revision 2.50/2.60: Serial displays as '0000-0000'
Serial is correct for standalone UDF revisions 1.02/1.50/2.00/2.01
Test Case: Run 'wine cmd' to open the command line and observe the output of
the `vol` command. Output differs from `vol` run on a native windows system for
the above volume types.
History: UDF support was introduced as a patch for bug #26273
http://bugs.winehq.org/show_bug.cgi?id=26273 and is hardcoded to use the 257th
sector (Address 526336) for serial calculation.
The actual sector used for serial calculations depends on the UDF revision and
volume type. I suspect the sector may be coded somewhere in the UDF
Specifications, and if that is the case then it should be a better solution
than hardcoding.
Serial calculations:
* Sector 257 for UDF revisions 1.02/1.50/2.00/2.01
* Sector 260 for ISO9660+UDF revisions 1.02/1.50/2.00/2.01
* Sector 320 for UDF revisions 2.50/2.60 with or without ISO9660
--
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=30444
Bug #: 30444
Summary: Microsoft SQL Server Management Studio Express
(SSMSE): opening new query window fails due to atl80
insufficiency
Product: Wine
Version: 1.5.2
Platform: x86
URL: http://go.microsoft.com/fwlink/?linkid=65212
OS/Version: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: atl
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: djelinski1(a)gmail.com
Classification: Unclassified
Created attachment 39803
--> http://bugs.winehq.org/attachment.cgi?id=39803
log of ssmsee.exe - steps as described.
To reproduce:
- run application
- connection window appears. Cancel this window.
- click New query button in the top toolbar. Another connection window
appeaers. Connect to a running instance of MS SQL Server.
A message box informing about an unhandled exception appears. It is possible to
click Continue, however the window that appears is unusable.
It used to work fine in wine-1.5.1. The commit that broke was "atl80: new dll".
There exists an easy workaround - start winecfg and in libraries tab set atl80
to native - the native dll is installed by application installer, so no further
steps are required.
winetricks dotnet20 and a recent version of windows in winecfg is needed to
start the application. Running instance of SQL Server is needed to reproduce
this bug.
--
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=22856
Summary: Runes of Magic 3.0.x: crashes at startup
Product: Wine
Version: 1.2-rc1
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P5
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: florianmattner(a)online.de
Wine crashes when I open the Client.exe
Wine says that the ClientUpdater.exe has been crashed.
--
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=25717
Summary: Japanese fonts sometimes shifted to the left
Product: Wine
Version: 1.3.11
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: gdi32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: galtgendo(a)o2.pl
Created an attachment (id=32764)
--> (http://bugs.winehq.org/attachment.cgi?id=32764)
output with WINEDEBUG=+font
After I set up new set of font overrides (first app I encountered, that was
looking up MSPGothic by its Japanese name), I ran into a strange effect.
While fonts in menus were rendered correctly (well, AFAICT), glyphs in other
places were shifted a bit to the left, as shown on the screenshot.
Attaching log from WINEDEBUG=+font first.
--
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=24621
Summary: Slow UI and toolbar redraw in SolidWorks
Product: Wine
Version: 1.3.4
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: denis.bonnenfant(a)diderot.org
In SolidWorks, toolbars are organized in tabs, displayed contextually depending
on actions ( sketching, 3D functions... ).
Left panel displays a tree view, or functions properties.
toolbars :
Manual switching between tabs works normally, no slowdown, but sometimes tabs
are drawn outside of the application window, at the top left of the screen,
just below system bar (see screenshot). Moving windows erases this.
When tab switching is initiated by another operation, the refresh logic is not
good : first, toolbar is displayed, but then it is redrawn very slowly (1-2s,
left to right). This operation slows down all the UI, resulting in a very
unpleasant lag for user (icons can't be selected during redraw)
Left panel (property manager) :
It contain collapsable areas, containing different dialog boxes ( see
screenshot ).
On any updates, left panel is first displayed correctly and quite fastly. But
then titles of collapsable boxes and some graphic areas are erased very slowly
(1-2s, left to right) (see screenshot). This operation slows down all the UI,
resulting in a very unpleasant lag for user too
--
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=19465
Summary: _mktime64 does not work with time/dates after 2038
Product: Wine
Version: 1.1.26
Platform: PC-x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: msvcrt
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: spencercw(a)googlemail.com
Created an attachment (id=22617)
--> (http://bugs.winehq.org/attachment.cgi?id=22617)
Sample program showing the bug
A simple example program is attached. Any attempt to use _mktime64 with a date
after ~2038 (i.e., any date that would require a 64-bit timestamp) returns -1
in Wine, but works ok in Windows (the example program shows 29348006400, tested
WinXP 32 and Win7 64, cross compiled mingw32 4.4.0).
Since there doesn't appear to be any way to force UNIX mktime to return a
64-bit value, I suspect the only work-around for this would be to re-implement
mktime in Wine.
--
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=25808
Summary: shdocvw:ie tests crash on x64 and clang
Product: Wine
Version: 1.3.11
Platform: x86-64
OS/Version: Linux
Status: NEW
Severity: minor
Priority: P2
Component: shdocvw
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: austinenglish(a)gmail.com
Created an attachment (id=32883)
--> (http://bugs.winehq.org/attachment.cgi?id=32883)
clang output
Clang:
../../../tools/runtest -q -P wine -M shdocvw.dll -T ../../.. -p
shdocvw_test.exe.so ie.c && touch ie.ok
wine: Unhandled page fault on write access to 0x00000028 at address 0x6821ce56
(thread 0039), starting debugger...
Unhandled exception: page fault on write access to 0x00000028 in 32-bit code
(0x6821ce56).
wine64:
fixme:storage:create_storagefile Storage share mode not implemented.
tmarshal.c:1735: PSFacBuf_CreateProxy: Assertion `sizeof(TMAsmProxy) == 16'
failed.
wine: Assertion failed at address 0x2b3a3663bba5 (thread 0009), starting
debugger...
Unhandled exception: assertion failed in 64-bit code (0x00002b3a3663bba5).
I'll attach logs for both.
--
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.