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
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
https://testbot.winehq.org/JobDetails.pl?Key=25415
Your paranoid android.
=== w1064 (32 bit locale) ===
locale.c:2562: Test failed: LCMapStringEx should fail with bad locale name
locale.c:2563: Test failed: unexpected error code -559038737
locale.c:2654: Test failed: Expected lcid == 0, got 00001000, error -559038737
locale.c:4384: Test failed: IsValidLocaleName should have failed
locale.c:4386: Test failed: IsValidLocaleName should have failed
locale.c:4769: Test failed: For id 7, expected ret == 4, got 1, error 87
locale.c:4771: Test failed: For id 7, Expected IVC, got ''
=== w1064 (64 bit locale) ===
locale.c:2562: Test failed: LCMapStringEx should fail with bad locale name
locale.c:2563: Test failed: unexpected error code -559038737
locale.c:2654: Test failed: Expected lcid == 0, got 00001000, error -559038737
locale.c:4384: Test failed: IsValidLocaleName should have failed
locale.c:4386: Test failed: IsValidLocaleName should have failed
locale.c:4769: Test failed: For id 7, expected ret == 4, got 1, error 87
locale.c:4771: Test failed: For id 7, Expected IVC, got ''
I'd like to take a try at Directx10 support, firstmost hacking the HLSL
compiler (namely implementing "fx_4_0"). No guarantee I'll succeed though.
First, is there already someone working on this? Don't wanna duplicate the
effort again.
Second, since there already is an existing parser: Did you plan to simply
extend it and make one parser for all HLSL versions, or to duplicate the code
and have it separate for each version like the official compiler did it? I think
I'd just add it to d3dcompiler_43.
I’m trying to understand the memory usage of Wine. My focus is to make EVE Online run on the Mac as smoothly as possible, and one of the issues I’m running into is that the game runs out of memory in heavy scenes, especially when running at high resolutions on Macs with Retina screens.
On Windows, a scene with 300 ships in space may be running in 2.1GB of page file usage, but the same scene under Wine will show a Virtual Memory size of 3.5GB or more. Once the Virtual Memory size (as shown by the Activity Monitor) gets too close to the 4GB mark I start getting errors from Wine, failing to allocate memory, usually leading to a crash.
There is a significant difference even when running at the same resolution on both Windows and Mac, and further pronounced if I run in the full 5k resolution of an iMac.
Can anyone explain this big difference in memory use between the Windows and Wine sessions? Or give me ideas on how I can figure it out? Or better yet, have suggestions on how to reduce it?
Best regards,
Snorri Sturluson
CCP Games
TL;WR: I'd like to share a struct definition between ntdll and
kernel32, passed through the PEB. Is this kosher according to Wine
style/design, and if so, which header should I stick it in?
--
I'd like to have fiber-local storage callbacks in Wine.
http://source.winehq.org/git/wine.git/commit/556fef3dhttp://source.winehq.org/git/wine.git/commit/ab11a5aehttp://source.winehq.org/git/wine.git/commit/4e8f43f4
So, after writing the conformance tests, it's time to implement the feature :-)
I've got the feature all done, except for one issue. The proximate
issue is that when NtTerminateProcess is used on Windows, FLS
callbacks are not called for threads that are aborted (and those
threads do not get a DLL_THREAD_DETACH notification). However, if
during DLL_PROCESS_DETACH the FLS slot is then freed, then the
callbacks are called on behalf of those (already-terminated) threads
by the process-detaching thread. The behavior appears to be thus: if
the thread is exited cleanly (through LdrShutdownThread), then the FLS
callbacks are called for that thread; otherwise on an unclean exit the
FLS slots for the thread are transferred to some global list, and the
callbacks for that list are called when FlsFree is later called.
The underlying problem regards doing that transfer to the global list.
LdrShutdownThread and its other friends reside in ntdll, so ntdll will
have to know how to manage FLS. The FLS API however resides in
kernel32, so kernel32 will have to know, as well. For this purpose
I'd like to pass a common struct between ntdll and kernel32 through
PEB.FlsListHead. What I see though is that include/winternl.h
contains (almost all) publicly Microsoft-documented struct
definitions, and I don't see anywhere else where such common structs
are presently shared between two DLLs. So is it the case that the
convention in Wine is to not do such things as sharing structs, or is
this also done elsewhere and I just need to find the right header for
it?
Thanks,
-John Sheu
Currently looking at the directx11 implementation, and I noticed I first need
to set a "MaxVersionGL" in the registry to enable creation of 4.3 context and
so DX11 support.
What's the reason behind this?
The change is from a1e718ccabc7c330dd16c7face78022965b03e20 (wined3d: Add a
setting for the maximum OpenGL version to use).
Why do we need to set the maximum version instead of just using the highest
context we can get (and still use) ?
Fabian Maurer
2016-08-19 21:41 GMT+02:00 Ruslan Kabatsayev <b7.10110111(a)gmail.com>:
> This adds a 3d-demo wine application. It will allow users to check that their
> system can handle at least basic WGL, D3D8 and D3D9 before they need to look
> deeper into their problem.
>
> Signed-off-by: Ruslan Kabatsayev <b7.10110111(a)gmail.com>
> ---
> configure | 26 +-
> configure.ac | 1 +
> programs/3d-demo/Makefile.in | 14 +
> programs/3d-demo/common.c | 107 ++++++
> programs/3d-demo/common.h | 36 ++
> programs/3d-demo/d3d.c | 605 ++++++++++++++++++++++++++++++++
> programs/3d-demo/d3d8.c | 2 +
> programs/3d-demo/d3d9.c | 2 +
> programs/3d-demo/demo.rc | 61 ++++
> programs/3d-demo/main.c | 175 +++++++++
> programs/3d-demo/resource.h | 33 ++
> programs/3d-demo/wgl.c | 473 +++++++++++++++++++++++++
> programs/3d-demo/winehq_logo_glass.png | Bin 0 -> 31512 bytes
> 13 files changed, 1517 insertions(+), 18 deletions(-)
> create mode 100644 programs/3d-demo/Makefile.in
> create mode 100644 programs/3d-demo/common.c
> create mode 100644 programs/3d-demo/common.h
> create mode 100644 programs/3d-demo/d3d.c
> create mode 100644 programs/3d-demo/d3d8.c
> create mode 100644 programs/3d-demo/d3d9.c
> create mode 100644 programs/3d-demo/demo.rc
> create mode 100644 programs/3d-demo/main.c
> create mode 100644 programs/3d-demo/resource.h
> create mode 100644 programs/3d-demo/wgl.c
> create mode 100644 programs/3d-demo/winehq_logo_glass.png
I have a few pretty generic suggestions. You don't need to include
configure changes in the patch, they will be regenerated by Alexandre
anyway since those depend on the version of the autotools.
Did you look into adding those tests to dxdiag instead of as a
separate program? I don't think a separate program is necessarily bad
but if integrating into dxdiag is reasonable it's probably better to
do that from the start.
Avoid camelCase or similar mixed-case identifier styles, just use
lowercase_with_underscores. For pointer declarations you want to stick
the '*' to the variable, not the type. Also please avoid LPTYPES, just
use explicit pointer types.
C++ comments (// comment) aren't allowed in Wine sources. Please
replace them with normal C comments (/* comment */), or drop them
entirely if they don't add anything that isn't clear from just looking
at the code.
It would be better to use explicit float constants when assigning to
float variables (e.g. D3DMATERIAL).
There aren't many other general style rules in Wine (it's mostly about
using the style already used in the component so for new components
you're mostly free to pick your own) as long as there is consistency.
I see you mixing space after ',' with no space, pick one (preferably
the space variant IMO) and stick to it. We usually use parentheses
with the "sizeof" operator in Wine sources, so while it's not strictly
required it would probably be nice to follow the general trend.
More specific comments: I'd split this over multiple patches. You can
probably make an initial patch adding the program with no real
functionality, then multiple patches adding the various graphical API
demos. In that regard, the d3d8 / d3d9 "merged" handling via macros
seems a bit obfuscating to me. Just replicating the code twice seems
cleaner. Maybe you can create a few helper functions for the common
code.
BTW, you can probably make things a bit more structured by moving the
main loop to common code and have it call API backend functions. You'd
have for each backend a structure like:
static const struct render_backend d3d9_backend
{
d3d9_list_modes,
d3d9_init,
d3d9_draw,
d3d9_wndproc,
d3d9_destroy,
};
(just an idea WRT the actual functions, I haven't really looked in
detail) and you'd pass the structure from the selected API to the
"main loop" function.
I don't think you're using GLU anymore (good) so you should drop the
glu32 import.
I haven't looked in detail at the actual demos / renderers but I think
there is enough stuff to work on already :)