Looking at
RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector )
{
RPC_STATUS status;
ULONG c;
TRACE("(%p)\n", BindingVector);
for (c=0; c<(*BindingVector)->Count; c++) {
status = RpcBindingFree(&(*BindingVector)->BindingH[c]);
}
HeapFree(GetProcessHeap(), 0, *BindingVector);
*BindingVector = NULL;
return RPC_S_OK;
}
we currently always ignore the outcome of RpcBindingFree and return
RPC_S_OK.
However, there is one case where RpcBindingFree returns something
different (which is if *Binding is null when RPC_S_INVALID_BINDING
is returned).
What is the proper way of handling this? Just keeping the code as
is and removing the unused status variable? Breaking the loop once
RpcBindingFree returns something different from RPC_S_OK? Continuing
and returning the first / the last status different from RPC_S_OK?
Gerald
Dear all,
While test another online bank with wine ActiveX,
I got an unimplemented fuction of ntoskrnl: IoGetDeviceInterfaces,
I found it listed in http://source.winehq.org/WineAPI/ntoskrnl.html as a stup,
so I can't understand this log:
wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called
at address 0x7b839552 (thread 0022), starting debugger...
Grateful for any explain!
env:
wine1.3.12 on Ubuntu 10.04
Here are the steps:
1. install an ActiveX from
https://e.bank.ecitic.com/perbank5/plugs/CNCBSecPkg_EN.exe
$ rm -rf ~/.wine
$ winetricks -q mfc42
$ wine CNCBSecPkg_EN.exe
fixme:ole:DllRegisterServer stub
fixme:win:DisableProcessWindowsGhosting : stub
fixme:msg:ChangeWindowMessageFilter c057 00000001
fixme:msg:ChangeWindowMessageFilter c057 00000001
fixme:msg:ChangeWindowMessageFilter c057 00000001
fixme:ole:CoCreateInstance no instance created for interface
{ea1afb91-9e28-4b86-90e9-9e9f8a5eefaf} of class
{56fdf344-fd6d-11d0-958a-006097c9a090}, hres is 0x80004002
fixme:sfc:SfcIsFileProtected ((nil), L"C:\\Program
Files\\\4e2d\4fe1\94f6\884c\7f51\94f6\5b89\5168\63a7\4ef6\\unins000.exe")
stub
fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub!
fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 -1: stub!
fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub!
wine: Call from 0x7b839552 to unimplemented function
ntoskrnl.exe.IoGetDeviceInterfaces, aborting
wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called
at address 0x7b839552 (thread 002b), starting debugger...
wine: Call from 0x7b839552 to unimplemented function
ntoskrnl.exe.IoGetDeviceInterfaces, aborting
wine: Call from 0x7b839552 to unimplemented function
ntoskrnl.exe.IoGetDeviceInterfaces, aborting
2. open the online bank entry with wine builtin IE, then IE will crash:
$ wine iexplore https://e.bank.ecitic.com/perbank5/signIn.do
Please checkout the full log here:
http://pastebin.com/rbAg7gwj
Should I file a singel bug in ntoskrnl component , or separate bugs,
one for ntoskrnl and one for the IE crashing?
Generalliy what component should I switch while file a bug about IE crashing?
Many thanks!
--
Regards,
Qian Hong
-
Sent from Ubuntu
http://www.ubuntu.com/
Good Afternoon.
In section 3.3.6.2 of your User Guide you ask readers to report
successes with databases other than MS SQL. Well here's one (I know
Access 2000 can work with Wine, but this doesn't require Access):
How to set up Wine to enable Windows programs that read and write to Jet
(Access)
databases using ODBC. I write such programs in C and use the API defined in
ODBC API Reference
http://msdn.microsoft.com/en-us/library/ms714562%28VS.85%29.aspx
They work fine on Windows and only require Mingw to be installed to
compile and link them,
both for console programs and those using Windows SDK.
You then can write interactive programs in C which use a full-featured
SQL database which
comes bundled with Windows. No need to purchase Access.
With the set-up below they will also run on Linux (Kubuntu 9.04) and
Wine 1.1.26.
You need to update the registry to install the Access drivers.
Under Windows, export from the Registry to *.reg files the registry entries
- HKLM\Software\ODBC
- HKLM\Software\Microsoft\Jet
all subsidiary keys and values come with them.
You can carefully edit these files to remove drivers and DSNs you don't
need.
Import these files using the registry editor in wine:
wine regedit.exe.
You need to bring across from Windows to Windows\System32 under wine:
clbcatq.dll
comres.dll
expsrv.dll
msjet40.dll
mswstr10.dll
msjter40.dll
msjint40.dll
msjtes40.dll
msrd3x40.dll
odbc32.dll
odbccp32.dll
odbcji32.dll
odbcjt32.dll
odbcad32.exe
odbcint.dll
odbctrac.dll
vbajet32.dll
Register this server in wine:
wine regsvr32.exe msjtes40.dll
No need to install MDAC.
To use Windows ODBC drivers, you have to override Wine's odbccp32.dll
and odbc32.dll with the native
versions because the Wine versions are currently wired directly to
Linux's unixodbc.
This can be done by setting up the ODBC Data Source Administrator
odbcad32.exe using winecfg:
- Add the program to the Applications tab
- then in the libraries tab, pick from 'New override for library' drop-down
odbc32.dll and odbccp32.dll add them and edit them to be Native for Windows.
Then if you do
wine odbcad32.exe
this brings up the ODBC Data Source Administrator window as in the
Windows Control Panel
If needed, set up (System) DSNs using this program.
Bring across the programs and *.mdb database files from Windows.
Using winecfg, you need to set up each program you want to run with
overrides for odbc32.dll and odbccp32.dll
(Applications and Libraries tabs) as above.
The programs should then run as they did in Windows but perhaps a bit
slower with:
wine Odbc-prog.exe
This has been tested twice on a clean .wine install. I cannot vouch
for support of all API and SQL facilities however.
I hope someone finds this useful.
Barry Bird
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
Am 09.07.2009 um 02:58 schrieb Michael Gruber:
> This patch series implements parts of the XInput library. You can use
> this to play games that support Xbox 360 Controllers. To be able to
> use this you will need to have your Controller working on Linux via
> the xpad kernel driver and the event interface. It will not work on
> any OS other than Linux. It supports gamepads, should work with
> guitars and wheels, but will not work with dance-mats.
> <1-XInputGetState.patch>
Is it possible to implement XInput on top of DirectInput? DirectInput
already has some internal abstraction layers for differnet joystick
APIs, and has basic support for OSX joysticks. Does DInput have enough
capabilities to access all the Xbox controller's features? My gut says
no, otherwise MS wouldn't have created a new lib. I guess its worth
checking though.
Gerald Pfeifer <gerald(a)pfeifer.com> writes:
> A FreeBSD user ran into this when sys/inotify.h was present via an
> extra package and Wine went ahead using that, only to fail at link-
> time.
We'd want to use kqueue instead on FreeBSD.
--
Alexandre Julliard
julliard(a)winehq.org
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...
Folks,
There will a Wine devroom at FOSDEM '14 on Sunday, February 2, 2014.
Last year we had a great time, and I think it was valuable for us
to connect with the broader Free software community.
I'd like to now invite you to submit proposals for talks.
I'd really like to encourage everyone to think of something fun to share
with the 5,000 geeks that will be swarming Brussels.
If you have an topic you'd like to discuss, or an idea you want
to present, please submit it to:
https://penta.fosdem.org/submission
You will create an account (if you don't have one from a previous year),
and select the "Wine devroom" as the track. Please either submit
for lengths of 30 or 60 minutes.
The deadline for submissions is December 1st.
I think it would be great if we branched out a bit, and submitting a
crazy off the wall proposal will just burn churn a few electrons. So
submit it!
For further discussion, please follow up to wineconf(a)winehq.org.
Cheers,
Jeremy
We switched to the new WineTestBot near the start of September. Early on
it ran into a problem when it was flooded with tests due to the
__WINESRC__ tests work and it failed to keep up.
The reason is that as time went on the time it takes to get the VMs back
to a clean state ready to run the tests (the revert time) kept
increasing as can be seen on this graph:
http://fgouget.free.fr/wtb/vm1-revtimes.png
There one can see the increased activity in september that what was
caused by the surge in test patches. But the most remarkable feature is
the Windows XP revert times which increase linearly, reaching over 30
minutes. The revert times for the other VMs are much more random but
still seem to increase somewhat (1).
The reason for the increase is still unknown. The revert time fell down
a few times and now I suspect this corresponds to times when the VM was
restored from backup.
So at the start of October I upgraded to QEMU 1.6.0 and restored all the
VMs from backup, hoping this would solve the problem. The revert times
did get much better and the WineTestBot now manages to keep up:
http://fgouget.free.fr/wtb/vm1-revtimes-new.png
The upgrade happened around the 2nd of october and the revert times fell
at that point. But looking at more recent data it's clear that the
Windows XP revert times are increasing again, while those of the other
VMs remain stable (see vm1-revtimes.xls for the raw data).
That XP VM is one of the first ones I created, so it probably was
created with a pretty old QEMU version. Futhermore it was only an out of
the box SP2 and did not have any of the later updates. So I decided to
recreate it from scratch, using QEMU 1.6.0, and to add all the other
updates as I was at it. And I'm hoping that this time things will be
better. That's why this VM is currently in 'maintenance' mode.
I also took down the 32-bit Windows 8 VM for maintenance. It too is
missing proper updates and the plan is to upgrade it to Windows 8.1.
Another issue has been that the tests are running a bit slow, a
particular point of pain was msi:action and msi:install which were
regularly timing out. See:
http://fgouget.free.fr/wtb/runtimes.htm
So while rebuilding the Windows XP VM I did some performance tests. That
paid off. I found that switching the emulated disk cache mode from
writeback to default roughly halves the msi run times:
http://fgouget.free.fr/wtb/runtimes2.htm
msi:action and msi:install went from an average of 99 and 90 seconds
down to 48 and 39 seconds and they are not timing out anymore. The
remaining troublesome tests are now ddraw:ddraw{2,4,7}, shell32:shlexec,
and winspool.drv:info.
I also uncovered two other potential performance issues:
* Some VMs have Windows Defender and apparently it was starting a full
disk scan as soon as the VM was ready to run the tests. That's
clearly not good so I disabled Windows Defender in all VMs.
* Most VMs were still using 20% of the CPU when idle. That's fine if
only one VM is running but could impact performance (through
increased interrupt rates) if many are running at once (like on the
WineTestBot). Apparently the culprit is the USB Tablet device that's
added by default. So I removed it from all VMs too (and now the mouse
is even more laggy than before when I work on the VMs :-( But that
does not impact the tests).
So there is still a lot of work to do on the WineTestBot, and that's
not even counting fixing all the failing tests.
(1) It's almost as if the increasing Windows XP revert times were
pulling up the other VM revert times. Yet there's only one revert at a
given time, so I don't see how this would be possible.
(2) Setting the cache mode to writeback was improving the performance
quite a bit with the pre-upgrade QEMU version. But obviously it's not
true anymore. Another interesting point is that the Virtio mode improves
performance by a factor of 10 (down from 450 seconds to 45 in
msi:action). Yet Windows 8 posts the fastest times yet in the basic IDE
mode (~23 seconds). I couldn't get Windows 8 working with the Virtio
disk yet and I have not verified that it's really doing the same set of
tests. So that remains to be confirmed.
Here is some performance data taken from the Windows XP VM while the
TestBot was idle. From it cache=default looks like it's a completely
separate mode!
msi:action | msi:install | msi:msi
448 460 520| 487 439 | 238 229 VGA, qcow2 ide disk, cache:default
44 45 42 | 47 49 46 | 24 23 21 VGA, qcow2 virtio disk, cache:default
48 45 50 | 47 48 48 | 23 23 24 VMVGA/VGA, qcow2 virtio disk, cache:default
47 46 | 48 46 | 23 22 22 VMVGA, qcow2 virtio disk, cache:default
47 47 | 49 48 | 24 23 VMVGA, raw virtio disk, cache:default
62 67 67 | 64 60 63 | 29 27 27 VMVGA, raw virtio disk, cache:none
111 92 72 113 | 101 101 | 37 37 40 VMVGA, raw virtio disk, cache:writethrough
61 64 53 | 70 59 58 | 36 28 29 VMVGA, raw virtio disk, cache:writeback
46 44 | | VMVGA, raw virtio disk, cache:default
71 55 68 | | VMVGA, raw virtio disk, cache:writeback
65 71 72 69| | VMVGA, raw virtio disk, cache:none
76 118 111 | | VMVGA, raw virtio disk, cache:writethrough
50 48 47 | | VMVGA, raw virtio disk, cache:default
And the preliminary Windows 8 performance. I hope it holds up.
msi:action | msi:install | msi:msi
23 22 22 | 16 15 16 | 13 13 15 VGA, qcow2 ide disk, cache:default
--
Francois Gouget <fgouget(a)codeweavers.com>