Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=3105
Your paranoid android.
=== WNT4WSSP6 (32 bit resource) ===
No test summary line found
Hello,
Most fonts are missing some characters (S and T with a comma below, as
opposed to those with a cedilla; see [1] for a discussion) needed to
correctly represent some letters in the Romanian alphabet. Initially,
Windows XP did not include support for these characters, but it released an
update to fix this once Romania joined the EU. The update [2] contains the
fonts Times New Roman, Arial, Trebuchet, Verdana.
Winetricks should include a new trick to download this update and install
the 16 font files from the package. It would be nice to have something like
"corefonts w/ EU update" which would install the fixed fonts + the other
core fonts that are not included in this update. There is a small problem
caused by the casing of the filenames in this update (Times New Roman,
Arial, Verdana filenames have a different casing than the ones on SF.net),
so they should be renamed to match the original corefonts names. Also,
corefonts should not override the updated EU fonts if it detects them.
There is the general problem that most system fonts wine uses are missing
these characters, and some characters render incorrectly in dialogs. Most
notably, the find/replace dialogs in comdlg32 with ro_RO.utf8 locale are
completely broken font-wise: ă and î look bad, ț shows as a question
mark. "MS Shell Dlg" font is usually used in dialogs, but it doesn't show up
in the font selection dialog, so I'm not sure what font is actually used.
Try pasting the following text in notepad/wordpad and try various fonts to
see for yourself:
ă Ă - a with breve
â Â - a with circumflex
î Î - i with circumflex
ș Ș - s with comma
ț Ț - t with comma
ş Ş - s with cedilla (obsolete for RO)
ţ Ţ - t with cedilla (obsolete for RO)
Not sure how this issue could be fixed. Are the fonts we currently use open
source, can we edit them?
Octavian
[1]
http://en.wikipedia.org/wiki/Romanian_alphabet#Comma-below_.28.C8.99_and_.C…
<http://en.wikipedia.org/wiki/Romanian_alphabet#Comma-below_.28.C8.99_and_.C…>
[2]
http://www.microsoft.com/downloads/details.aspx?FamilyID=0ec6f335-c3de-44c5…
<http://www.microsoft.com/downloads/details.aspx?FamilyID=0ec6f335-c3de-44c5…>
Unfortunately, this is a FAQ, so I've added it. I based the answer on
the last time this came around on wine-users; I'm not a developer, so
please sanity-check what I wrote! Hopefully this will be useful in
dealing with the actual problems people think they can solve by doing
this.
http://wiki.winehq.org/FAQ#head-9c045f5ff1df8a1afef91e1152ca7f6a9684f116
8.6. I write a Windows app. How can it detect if it's running under Wine?
This is a bad idea. The goal of Wine is that an application will be
unable to tell it's running under Wine rather than Windows. So any
method to detect running under Wine is unsupported and may break
without warning in the future. Wine should not be treated as a
"version" of Windows - functionality or performance-tuning is likely
to be different between any two development versions.
Rather than detecting Wine:
* Detect if functionality exists and use it when available.
* File a bug if something works in Windows that does not work in Wine.
* Ask for help on the developers' list.
That said: if you really want to detect Wine, try, e.g., running a
native binary or syscall (AppArmor or SELinux may block this), reading
the environment, accessing a function (e.g ntdll.get_wine_version() )
or registry key only found in Wine. Any of these may break at any
time.
Asking the user directly if they are running the app under Wine will
be more reliable than trying to automatically detect it.
- d.
Hi, all
I found that WINEDEBUG=+relay works by dlls/ntdll/relay.c
and I'm trying to catch function call of dlls.
Wine doc says relay supports user32, ntdll, etc, but not gdi32.
However when I run wine, some gdi32 calls are caught, e.g, CreateBitmap()
But some aren't caught, e.g, CreateBitmapIndirect()
---------------------------------------------------------------------------------------------------------
$ WINEDEBU+relay wine notepad.exe
trace:bitmap:CreateBitmapIndirect 8x8, 2 colors returning 0x220
[relay_call:12] 000d:Ret gdi32.CreateBitmap() retval=00000220 ret=68849be9
---------------------------------------------------------------------------------------------------------
Both are gdi32 export function. Do you know why?
I want to catch all gdi32 function calls.
Thanks in advance.
Hayan
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=3073
Your paranoid android.
=== W2K3R2SESP2 (32 bit shlexec) ===
shlexec.c:195: Test failed: WaitForSingleObject returned 258
shlexec.c:1417: Test failed: argvA3 expected 'Open', got '(null)'
shlexec.c:1420: Test failed: argvA4 expected 'C:\WINDOWS\Temp\wt11.tmp\test file.shlexec', got '(null)'
shlexec.c:1426: Test failed: argcA expected 4, but got 5
shlexec.c:1427: Test failed: argvA3 expected 'Lnk', got 'Open'
shlexec.c:1516: Test failed: argcA expected 4, but got 5
shlexec.c:1517: Test failed: argvA3 expected 'Exec', got 'Lnk'
=== W7PROX64 (64 bit shlexec) ===
shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt2676.tmp\test file.sde", null, null) failed: rc=29 err=2
shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt2676.tmp\test file.sde", null, null) failed: rc=29 err=2
shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt2676.tmp\test file.sde", null, null) failed: rc=29 err=2
shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt2676.tmp\test file.sde", null, null) failed: rc=29 err=2
shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt2676.tmp\test file.sde", null, null) failed: rc=29 err=2
On Thu, Jul 1, 2010 at 5:20 PM, Matthias Kupfer
<matthias.kupfer(a)informatik.tu-chemnitz.de> wrote:
> Hi,
>
> after changing the selected tab, it's impossible to change to another tab with
> mouse. This patch fixes this issue, because the SetCurFocus changes selection
> (if conditions apply).
This patch has caused a regression, please see
http://bugs.winehq.org/show_bug.cgi?id=23479.
--
-Austin
I've found the following warning the the file comdlg32:
/*
* WARNING: DO NOT CHANGE THE SIZE OF THE STANDARD DIALOG TEMPLATES.
*/
Does that mean that I can't correct the size of the buttons or strings
that are wrong in the Portuguese template file? Or is that only a
warning for the English file? The "Find" and "Replace" dialogs are
specially ugly in Portuguese, I would appreciate to be able to change
that.
Sometimes, when a developer adds a string to En resource file, (s)he adds it
as well to all other non-En resource files.
Isn't that unnecessary?
http://wiki.winehq.org/SublangNeutral says the search order is
1. LANG_NEUTRAL, SUBLANG_NEUTRAL
2. LANG_FRENCH, SUBLANG_FRENCH_BELGIAN
3. LANG_FRENCH, SUBLANG_NEUTRAL
4. LANG_ENGLISH, SUBLANG_ENGLISH_US
Would a patch removing En resources in non En rc files be accepted? This
would allow for more accurate translation stats.
Or doesn't a fallback mechanism always apply?
Frédéric