Hello all,
I know this will only interest a small portion of you but thought i
would give a quick update on the state of IMM32 since I have brought it
to a major milestone.
All the main patches are in which now separate IMM32 and IMEs. There
is still more work to do but the major framework is in place. X11 XIM
processing should be unchanged. However wine can now begin to load
native windows IMEs as well.
I have tested with windows ATOK20 (a popular Japanese IME) and
successfully had text processing in a fully IME aware application. There
are still clear issues to resolve in many aspects of this processing but
we have forward progress.
ImmInstallIME does not work yet, nor does switching keyboards. So to
get the native IME to work you need to add this registry key.
[System\\CurrentControlSet\\Control\\Keyboard Layouts\\<keyboard layout>]
"Ime File"=<IME filename>
so for example for ATOK20 in Japanese i used.
[System\\CurrentControlSet\\Control\\Keyboard Layouts\\e0010411]
"Ime File"="ATOK20W.IME"
I would love to hear how well things work. I am sure using native IMEs
will quickly show us many places where IMM32 needs to be improved.
One issues I am going to investigate next is that sometimes non x11drv
ime initialization, if occurring too early, causes x11drv to fail to
create windows. I have not investigated with the latest changes to
xim.c (which may already correct this problem) but if you see this
problem this patch may help and i believe the
IME_UpdateAssociation(NULL) is already unneeded.
diff --git a/dlls/winex11.drv/xim.c b/dlls/winex11.drv/xim.c
index d4df9f7..0c98136 100644
--- a/dlls/winex11.drv/xim.c
+++ b/dlls/winex11.drv/xim.c
@@ -475,7 +475,6 @@ static void X11DRV_OpenIM(Display *display, XPointer
ptr, XP
XUnregisterIMInstantiateCallback(display, NULL, NULL, NULL,
X11DRV_OpenIM,
wine_tsx11_unlock();
IME_XIMPresent(TRUE);
- IME_UpdateAssociation(NULL);
}
thanks,
-aric
What happened to the Fedora packages? They have not been updated since
0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro
supported has the up to date packages!!! And why does the Red Hat packages
site not go to the SourceForge site as it does for SUSE packages and the
others?? I have not really had the guts to ask until now, because I thought
that maybe there was a slump, but now, its getting annoying!! And Fedora
just released Fedora Core 5 yesterday!!! Please tell me new packages will be
ready soon!!! Compiling WINE always crashes my computer, so I prefer to use
the RPMs...
Hi.
>From which configuration does the "ERROR_INVALID_NAME" came from,
when calling GetDefaultPrinter(NULL, &size) and no Printer is installed?
This Test is Present in the current "dlls/winspool/tests/info.c".
MSDN told us, that we receive an "ERROR_FILE_NOT_FOUND", if no Printer
is installed:
http://msdn.microsoft.com/library/en-us/gdi/prntspol_0hma.asp
I get the "ERROR_FILE_NOT_FOUND" on win98se, winme, w2k and win2003 in
this Situation.
--
By By ...
... Detlef
Maarten wrote:
> Why don't we have wine t-shirts any more?
I dunno, where were they before?
I just looked, couldn't find any on cafepress.com.
I'd like to bring back the Codeweavers drunken penguin
t-shirts, perhaps with a slightly more generic Wine
design.
Coincidentally, I found some site on the net had taken
the logo from that shirt and erased the Crossover
logo from the wine bottle; here's a cleaned-up copy:
http://kegel.com/wine/wine-penguin-corkscrew.png
Hi,
I know that CodeWeavers supports quite nicely Mac builds of Wine, and
CrossOver for Mac, yet all of them are X11.
There was also once Darwine - an effort to provide Carbon Wine UI
driver and Mac optimizations & L&F.
Pretty many of those were merged back to Wine, but not winequartz.drv.
Do you guys think about reviving winequartz.drv?
This would greatly improve Wine on Mac as we could have native Mac
fonts handling that's faster than FreeType, Dock icons for Wine
applications, and few others.
There's still old copy of the it hanging around, but it is abandoned,
and no longer compiles with Wine.
Or I think it would be cool to write new winecocoa.drv or sthing like
that, as Apple officially states that Carbon is deprecated.
While it is not well documented, it is pretty easy with Cocoa to make
console non-bundled process to be UI foreground process and handle
events and Dock:
(This code is copyrighted by myself ;P)
> int main(int argc, const char * argv[]) {
> ProcessSerialNumber psn = {0, kCurrentProcess};
> OSStatus returnCode = TransformProcessType(&psn,
> kProcessTransformToForegroundApplication);
> SetFrontProcess(&psn);
>
> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> [NSApplication sharedApplication];
>
> NSImage *icon = [NSImage imageNamed:@"NSApplicationIcon"];
> [NSApp setApplicationIconImage:icon];
>
> [NSApp finishLaunching];
>
> NSWindow *window = [[NSWindow alloc]
> initWithContentRect:NSMakeRect(0, 0, 100, 100)
> styleMask:NSTitledWindowMask|
> NSClosableWindowMask|NSMiniaturizableWindowMask|NSResizableWindowMask
> backing:NSBackingStoreBuffered defer:NO];
> [window center];
> [window setTitle:@"Test"];
>
> NSButton *button = [[NSButton alloc]
> initWithFrame:NSMakeRect(10, 10, 80, 80)];
> [button setTitle:@"What?"];
> [button setBezelStyle:1];
> [[window contentView] addSubview:button];
> [button release];
>
> [window makeKeyAndOrderFront:NSApp];
>
> while(1) {
> NSEvent *event = [NSApp
> nextEventMatchingMask:NSAnyEventMask
> untilDate
> :[NSDate distantFuture]
> inMode:NSDefaultRunLoopMode
> dequeue:YES
> ];
> if(event) [NSApp sendEvent:event];
> }
> [pool release];
> return 0;
> }
BTW. I heard that someone previously working for Wine project is now
in Apple, it is true?
Regards,
--
Adam Strzelecki |: nanoant.com :|
I *almost* have a great success story to report; the only thing
keeping it from being a success story is the current directory
chosen by Nautilus when double-clicking on .exe files.
My wife hurt a finger trying to impersonate a Sampsonite Luggage gorilla,
and had to go to a hand doctor. Along the way her hand got x-rayed,
and the doctor handed her a cd-rom with the x-ray pictures on it.
The disc has an autorun.inf on it that should start ViewSel.exe.
I don't know if that's supposed to work with Wine and Nautilus, but
probably doubleclicking on ViewSel.exe does the same thing.
ViewSel.exe puts up two big buttons:
low res (which launches a web browser on an html file),
and high res (which launches a DICOM viewer).
If you cd to the root of the cd-rom drive and run ViewSel, it works.
If the current directory is anything else, it doesn't work.
If you start the autorun app via Nautilus, those buttons don't work,
so presumably it sets the current directory to something other than
the root of the drive. To see, I created a wrapper shell script, ~/bin/mywine,
containing
#!/bin/sh
pwd > /tmp/log
and used "Start with" to launch ViewSel.exe with ~/bin/mywine.
This showed that the current directory was $HOME.
I had a look at the gnome code to see how it decided, but it was
a bit hard to follow. (See gnome_vfs_mime_application_launch_with_env.)
So I tried a little shell magic. I created a new wrapper shell script
that assumes the argument is a path to a file, and
sets the current directory to the directory containing that file:
#!/bin/sh
DIR=`dirname "$1"`
DIR=`cd "$DIR"; pwd`
cd "$DIR"
wine "$@"
That worked better; it let ViewSel.exe launch the DICOM viewer.
So... I suppose the next step is to look at the debian/ubuntu packages
for wine and see if that little wrapper script could be incorporated
into the default way file browsers start wine?
It sure would be nice if apps that expected the current directory
to behave like this (it's not uncommon!) Just Worked.
- Dan
Adobe Contribute 4, released in Nov 2006 or so, had a nice online trial at
http://trials.adobe.com/Applications/Contribute/Adobe_Contribute_4_Win/Adob…
and still online, I think, at
http://www.soft32.com/download/63-129953-1/Adobe_Contribute_4_Win.exe
Starting it fails with
err:module:import_dll Library MSVCP71.dll (which is needed by
L"C:\\Program Files\\Adobe\\Contribute 4\\CoreTypes.dll") not found
Wine has a nice implementation of msvcr71.dll, but not
the C++-oriented msvcp71.dll, nor is it likely to get one soon.
This brings back the question: what's a good place to
legally and freely download an application bundled with a full set
of msvcp71.dll et al? Ideally something at Microsoft.com
and/or something small and suitable for use in winetricks.
Any ideas?
- Dan
Hi.
There was a problem found recently in a fan-made mod of Forsaken (game), that
certain input combinations were slowing wine very seriously. Holding down a
keyboard button and moving mouse was found to be especially devastating to
performance (200 fps to 10fps in a matter of 10-20 seconds).
With help from people who develop this mod, I was able to isolate it in a very
small and simplistic testcase, which shows this same problem. It will be
included as attachment. Holding a key and moving mouse over the window steadily
increases main loop latency from 10 to 50 (and even 100) in a short time,
especially so if quickly clicking both mouse buttons as well. In a game this
means going from 100 fps to 20 or 10 just because of input messages. Has to be
noted that in the actual game the rate of slowdown seemed at least 2-3 times
faster for reasons I don't know, but the testcase still should enough to show
the problem.
Now, I do realize that what the testcase is doing is bad practice, it's
basically refusing to process certain types of messages, and PeekMessage just
once during a loop is probably bad as well, but that's what the game was
originally doing in its main game loop. They do plan to fix it in the game.
Still, there are several concerns about it:
1) No slowdown happens of Windows as far as I can tell. No matter how much I
move the mouse holding key and clicking madly, it shows same stable 15-16 ticks
latency in the testcase. I don't know what it does, but somehow it handles this
situation better than Wine.
2) Can this (broken) way of doing things be exposing some inefficiency in
message handling, maybe something that could use optimization? I tried to put
debug hacks into queue_hardware_message(), it seems that when slowdown is
already VERY bad in Forsaken (10fps), message queue in wine server has about 400
or maybe 600 messages. Is that kind of processing overhead per message
inevitable? (This is happening on AMD Athlon(tm) 3200+). Perhaps somebody who
knows that part of code well may be interested in looking into performance
issues in this case. Because, if 400-600 messages in the queue slow down the
application to a crawl, then who knows, perhaps it decreases performance of more
well-behaved but input-intensive apps as well, just less drastically (holding
one or several keys to move, all the while aiming with mouse and abusing mouse
buttons is a common thing in games, so there can be quite a few input messages
flooding the server).
The reason I decided to post it to wine-devel is because I'm not sure if this
kind of thing is expected and unavoidable or a bug that can be fixed, so better
to hear some comments first, then a bug entry can be opened if needed.
#include <windows.h>
HWND window;
int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
WNDCLASS wc = {0};
MSG msg;
DWORD ticks, ticks2;
HHOOK kbd_hook, mouse_hook;
wc.lpfnWndProc = &DefWindowProc;
wc.lpszClassName = "testwc";
RegisterClass(&wc);
window = CreateWindow("testwc", "test", WS_OVERLAPPED | WS_VISIBLE | WS_CAPTION , 0, 0, 640, 480, 0, 0, 0, 0);
ticks = GetTickCount();
for (;;) {
if (PeekMessage(&msg, NULL, WM_NULL, WM_KEYFIRST, PM_REMOVE)) {
if (msg.message == WM_QUIT) {
DestroyWindow(window);
break;
}
TranslateMessage(&msg);
DispatchMessage(&msg);
}
//simulated work
ticks2 = GetTickCount();
for (;;) {
UINT i;
volatile int dummy = 1;
for (; i < 10000 && dummy; i++) ;
if (GetTickCount() - ticks2 >= 10) break;
}
printf("main loop %u tick latency\n", GetTickCount() - ticks);
ticks = GetTickCount();
}
}
Big news: as of today or so, wine doesn't need any patches
to install the .net 2.0 runtime or run trivial .net 2.0 apps,
so I've added a dotnet20 verb. No more futzing with recipes
to try out simple .net 2 apps, huzzah!
There are lots of other little changes, too:
20080402
r21 Added dotnet20, removed one kludge from dotnet11, added win2k
verb, plus shorthand for winver=foo
r20 Updated liberation fonts.
20080328
r19 Added flash.
20080326
r18 Fix i18n problem reported by Ricardo Cabral
20080321
r17 Added msls31 (seems to be needed by e-Sword)
20080317
r16 update mono12 to 1.2.9
...
As always, winetricks is downloadable from
http://kegel.com/wine/winetricks
and change history is at
http://code.google.com/p/winezeug
Thanks to the folks who keep feeding me improvements and suggestions!
- Dan
Online at http://kegel.com/wine/valgrind/20071002/
(I now include more info about memory leaks, but I still
only report anything if there was an invalid memory reference.)
The following tests were fixed in git yesterday, and no longer have
any valgrind warnings:
comctl32/rebar
comctl32/status
crypt32/chain
crypt32/crl
crypt32/msg
cryptnet/cryptnet
user32/msg
wintrust/softpub
Juan thinks nearly all of the remaining crypt32 errors can be suppressed
(some are intentional).
Here are the directories that still have warnings:
advapi32 advpack cabinet comctl32 crypt32 d3d8 d3d9 d3dx8
dplayx dsound gdi32 gdiplus hlink kernel32 mlang msacm32
mscms mshtml msi msvcrt msxml3 netapi32 ntdll ole32
oleaut32 quartz riched20 riched32 rpcrt4 rsaenh setupapi
shdocvw shell32 urlmon user32 usp10 wininet winmm wintrust
- Dan