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
So this time I've done things in the right order: first publish the code
and then announce it.
So here's wt-daily, a script to "orchestrate all the daily WineTest runs
and related tasks."
Here's the 'quickstart guide':
git clone https://github.com/fgouget/wt-daily.git
cd wt-daily
vi wt-daily.config
In this file set the following environment variables:
email="your email address here"
tag="a-tag"
desc="A description of your system for Wine developers"
shutdown="suspend"
Then when you know you won't be needing your computer for a while, just
type ./wt-daily. This will update and rebuild Wine, run the tests and
finally suspend your machine.
It's that simple!
If you'd rather not suspend your machine you can set shutdown to
"poweroff", "reboot" or even leave it out to keep the computer on.
By default wt-daily will ask for your green light before starting the
tests. So you can start it while still using the computer and click 'Ok'
once you take off. To have the tests run automatically (e.g. from cron),
pass --auto-test on the command line or set default_options="--auto-test"
in the configuration file.
If you have a 64-bit system then you can also set the {tag,desc}wow32
and {tag,desc}wow64 variables to run the tests in a mixed 32/64-bit
WinePrefix. If you have a Mac, set the {tag,desc}mac variables to run
the tests using the Mac driver instead of (or in addition to) X11.
The script should work on OS/X though I have obviously not tested it in
a long time. I'ĺl be happy to get feedback on that, particularly in the
form of patches.
Now you can totally stop reading here. But there's a ton more that the
script can do. Read on if you want to discover more.
You can have the script start an application that will prevent the tests
from running until you close it. I used that to run the tests on a
MythTV client box. Wine would get updated and rebuilt in the background
while I was watching TV and once that was done the script would run the
tests and finally power off the computer.
You can also take an image of a suitably configured Windows partition
and have wt-daily restore that image to the partition, reboot to Windows
which will automatically run WineTest (you'll find the batch script for
that in the repository), then reboot back to Linux (or shutdown the
computer).
This functionality is used on the cw1-hd6800 and xw2-gtx560 CodeWeavers
boxes to run the tests on Linux, then Windows 8.1 and then Windows 10.
All automatically. The script actually runs every hour and skips the
tests (and rebooting) if nothing changed since the last run.
I also have this Windows image thing set up on my fg-acer64 laptop but
there I interactively select which Windows image to restore, with a
choice of Windows 8, 8.1 and 10 (or nothing if I don't feel like going
through a reboot).
You can also extend wt-daily to add non Wine tasks. For instance on my
laptops it runs another script that synchronizes the Documents folder
with my desktop and runs 'git fetch --all' in all my Git repositories.
This way the next time I go offline everything is up to date.
The repository also contains a number or scripts that you may find
useful in your own automation tasks as they support not just Linux but
OS/X too.
wt-image Creates, checks, restores or reboots to a disk image.
wt-bot Update, build and check the Wine source code, and run the tests.
wt-make Seeks to automatically fully use CPU and I/O parallelism when running make.
wt-ask Asks a simple Yes/No question to the user.
wt-notify Displays a notification to the user.
wt-power Powers off, reboots, suspends or hibernates the computer.
wt-screensaver Controls the screensaver. In particular it can prevent it from triggering.
wt-nice Runs the specified command with the lowest possible CPU and I/O priority.
--
Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/
Linux: the choice of a GNU generation
Howdy all,
As Alexandre mentioned [1], at WineConf we made several decisions to
modify bugzilla in a few ways. I've now implemented those changes,
which are outlined below:
* New wine-staging product: This should be used for bugs caused by
patches that are in wine-staging, but that do not occur in
wine-development (i.e., wine-staging patch regressions)
* New STAGED resolution: This is to differentiate bugs that are FIXED
(in wine-development) from bugs that are not present in wine-staging
because of one or more patches. The anticipated workflow is:
UNCONFIRMED > bug confirmed, NEW > patch written and sent to
wine-patches, if it's accepted, FIXED. If not, and the patch is
integrated into wine-staging, then the bug is STAGED. When the patch
is revised and eventually integrated into wine-development, the bug
should move to FIXED.
* New NEEDINFO resolution: There's a lot of confusion and different
handling by triagers for what to do with bug reports that are
incomplete (i.e., leaving it open versus closing invalid). To mitigate
this, I've added a NEEDINFO resolution. If a bug report lacks needed
information, set it to this status. Bug that have been open NEEDINFO
for more than 1 year can be closed.
* Renamed UPSTREAM to NOTOURBUG: This is more in line with what other
projects do, and eliminates confusion about the upstream/downstream
distinction.
Please let me know if there are any questions or ideas for further enhancements.
[1] https://www.winehq.org/pipermail/wine-devel/2015-September/109392.html
--
-Austin
Hi all, a possible way to solve the WSACleanup in the DLL side is to
retrieve all existing sockets from the current process in a server
call and then closing then inside winsock. Is it possible to make a
wine server call that returns variable length data? If yes, can anyone
show an example?
Such function would also allow for a proper implementation of
SetTcpEntry (iphlpapi) which would make firewalls that like to close
TCP connections happy.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Am 2015-09-13 um 22:56 schrieb Gerald Pfeifer:
> -#define D3DCOLOR_ARGB(a,r,g,b) ((D3DCOLOR)((((a)&0xff)<<24)|(((r)&0xff)<<16)|(((g)&0xff)<<8)|((b)&0xff)))
> +#define D3DCOLOR_ARGB(a,r,g,b) ((D3DCOLOR)((((a)&0xffu)<<24)|(((r)&0xff)<<16)|(((g)&0xff)<<8)|((b)&0xff)))
Wouldn't it make sense to make the masks for the other channels unsigned too?
Are there any possible side effects when compiling code with winelib? The native header uses a signed 0xff.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJV9o1AAAoJEN0/YqbEcdMwVwUP/3G2g6LM41sKgJt3/mxlhkQ4
BdxJ+Oj2Sz1FdefWNzohcRGI5V8AaRSfoCyCQCvSvFRUm72VY9aMKvK3Nhg7gku0
OmP9z81GEDIb13eLNGrcGNmU97wsqk69MtahHFZ3tj8gYLEWVW3sZPwU64VOa89g
7eLLrx5xXGAhoyzN/q85rV7oGj6xmCzv8YKzasv7BAQIdARVwoSVzmyH2kqbuJFf
ENVHyoPSJpphYBc4vxSOLVelgVCGEeAdAECnaGpGG+UfT8Sha3GTFu5q6Nn8P9Gx
3irwIPv7nfgqgdBFDRZUOuck/P5mirM9K3YQLB5309usVh7czusvR6LRWR7g5/gD
aCf3fub02sfVe0+Sl2NBMfjF361qaOcMpv63e6+QGToKRIXSE9Ht/v4oUeblNi+h
H6K/ljyv/kXr9mDUQBRbRUFlcKtp9Cm49xHAK7cT2xDrIj9z18mExKeARz+V1hiF
Fs9W/sJao6F+LN9p1XpdZ+Ha10zvFUrsF3OPj09nyv/C+lXdIt5WgFIiI6gzsD/Z
+vKFEoiYWnea9xBO9hUprnr4HTNlCMCZroQrvgeJm3xVxhcZZ9d7XQk7Q+oS1UlU
S1g4FJL/Ea8EPNW5bq35F9x50azgZVKmdgIDe1ZtogDF+tgGwuuHN5DiqHAhU2cM
deINoftjzz/ztYWqm2Yh
=kZgE
-----END PGP SIGNATURE-----
Hi,
I had a problem with Majesty Gold HD running at glacial speed on my
machine (quad Core i5 2.9GHz, NVidia GeForce GT 750M 1GB, OS X 10.9.5).
I'm using wine 1.7.35, but I've had similar problems with older wine
versions. It's a DirectDraw7 game that has been partially remastered to
run on modern systems, but still uses DirectDraw7.
This is a common problem on Windows too, but generally can be resolved
by telling the game to use the DirectDraw blitter (instead of blitting
itself). That didn't help on Wine though.
I profiled wine (Instruments time profile) and noticed that most time
was spent in wined3d's convert_r5g6b5_x8r8g8b8. Replacing that routine
with an optimized sse2 version from pixman did not make much of a
difference.
Then I discovered that if I told the game to render to a 16 bit instead
of to a 32 bit surface, wine would let OpenGL handle the colour
conversion. Unfortunately, while this significantly reduced wine's cpu
usage, it by no means made the game any faster. Looking at the OpenGL
Driver Monitor stats, it seems the cpu was simply waiting all the time
on the GPU, probably while it was blitting all of those 1920x1080 images
to the screen. Reducing the resolution to the lowest supported by the
game (800x600) made it slightly faster, but not much.
Next, I added the DirectDrawRenderer registry key and set it to gdi.
Now, while it's still slow at 1920x1080, the game runs much faster at
800x600 and even still at 1024x768. Profiling the gdi renderer shows
that it has way higher cpu usage than the OpenGL renderer (virtually all
in convert_to_8888), but it seems that for some reason it has causes
much less traffic to the GPU.
The wiki's wording suggests the gdi renderer is deprecated though. Does
that mean this qualifies as a bug in the OpenGL renderer (maybe it tries
to update the screen more often than necessary, saturating the bus that
way?), and are there any things I can try to narrow down why the gdi
renderer is so much faster? I didn't immediately see where it blits
things actually to the screen.
Thanks,
Jonas