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
This is a truly weird one. dinput8:dinput start failing on the 17th, the
day after WineHQ was upgraded:
https://test.winehq.org/data/tests/dinput8:dinput.html
What makes this weird is that:
* There has been no change to these tests between bd332f53f2d7 and
966a07149a02. In fact the last patch goes back to 2013.
So it's not a bad patch.
* The failures happen on every 32 bit test environment, from XP to
Windows 10, VM or not, TestBot or not. Only 64 bit is spared.
* I compiled a dinput8_crosstest.exe binary bd332f53f2d7 which
was not failing according to the test.winehq.org results. But all I
got is failures:
- 887b445bb878, 8th, 0 test.winehq.org failures, 13 here:
https://testbot.winehq.org/JobDetails.pl?Key=21611
- bd332f53f2d7, 16th, 0 test.winehq.org failures, 13 here:
https://testbot.winehq.org/JobDetails.pl?Key=21610
- 329dfee70c35, 22nd, 13 test.winehq.org failures, 13 here
https://testbot.winehq.org/JobDetails.pl?Key=21609
My MinGW compiler is more recent than the one WineHQ was using before
the upgrade however. So I think this points to a compiler-related
issue.
The official WineTest binaries are build on WineHQ so I suspect the
MinGW upgrade is somehow responsible for the new failures.
However I don't know if the old compiler was masking them, of if the new
one is causing them.
Any ideas?
For reference:
* Debian Testing (my environment):
$ i686-w64-mingw32-gcc --version
i686-w64-mingw32-gcc (GCC) 5.3.1 20160205
* Debian 7 (close to former WineHQ environment):
$ i686-w64-mingw32-gcc --version
i686-w64-mingw32-gcc (GCC) 4.9.1
--
Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/
Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.
Hello guys,
it's that time of the year again where we start thinking about the next
WineConf.
Last year would already have been the turn for North America so the next
WineConf will happen definitely there.
Jeremy White / CodeWeavers, as always, was very generous and offered to
host it in Minneapolis (or was it St. Paul? ;).
But if you're in US / Canada and really hoped to host the next WineConf
now is your time to speak up! The Twin Cities are beautiful at -30 C but
we wouldn't mind seeing other places too.
bye
michael
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
On 31 March 2016 at 19:51, Matteo Bruni <mbruni(a)codeweavers.com> wrote:
> + shader_addline(buffer, "if (alpha_test)\n");
> + if (alpha_func != WINED3D_CMP_NEVER)
> + shader_addline(buffer, " if (!(%s[0].a %s alpha_ref))\n",
> + get_fragment_output(gl_info), comparison_operator[alpha_func - WINED3D_CMP_NEVER]);
> + shader_addline(buffer, " discard;\n");
Is there really an advantage to having the "alpha_test" uniform
instead of just mapping disabled alpha test to WINED3D_CMP_ALWAYS?
> @@ -973,6 +981,7 @@ struct ps_compile_args {
> WORD texcoords_initialized; /* MAX_TEXTURES, 8 */
> BOOL pointsprite;
> BOOL flatshading;
> + enum wined3d_cmp_func alpha_func;
> };
>
> enum fog_src_type {
> @@ -2022,6 +2031,7 @@ struct ffp_frag_settings
> unsigned char pointsprite : 1;
> unsigned char flatshading : 1;
> unsigned char padding : 5;
> + enum wined3d_cmp_func alpha_func;
"alpha_func" only needs 4 bits (3 if you just mask the 4th bit), so
would still fit in the padding. That applies somewhat to struct
ps_compile_args as well, although we may care less there.
On 29.03.2016 22:13, Bernhard Übelacker wrote:
> https://bugs.winehq.org/show_bug.cgi?id=39734
>
> This patch should avoid crash in acedrv11.sys.
> IoAllocateIrp is called with a stack_size of -128.
> Therefore ExAllocatePool gets a negative size value.
>
> Tested against Windows XP.
> (See the test based on wine-staging "driver testing framework" attached to the bug.)
> ( https://newtestbot.winehq.org/JobDetails.pl?Key=21722 testrun by Sebastian Lackner.)
>
> Try 1: https://www.winehq.org/pipermail/wine-patches/2016-March/148587.html
> Review 1: https://www.winehq.org/pipermail/wine-devel/2016-March/112476.html
>
> Changes since try 1:
> - Fix usage of wrong variable.
> - Use a better name for variable.
> - Simplify if statement.
>
> Signed-off-by: Bernhard Übelacker <bernhardu(a)vr-web.de>
> ---
> dlls/ntoskrnl.exe/ntoskrnl.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
Thanks for the updated version. Could you maybe also add a couple of additional tests
with charge_quota = TRUE? Since you are changing both versions, I'm fearing a bit that
your changes could break other situations. If there are no unexpected test failures it
looks good to me.
2016-03-29 17:22 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>:
> Signed-off-by: Paul Gofman <gofmanp(a)gmail.com>
> +enum pres_reg_tables
> +{
> + PRES_REGTAB_IMMED, /* immediate double constants from CLIT */
I don't quite recall, I might be contradicting my own earlier comments
here but at this point this comment doesn't seem to add much.
General (and late) note, we usually tend to be more verbose with
variable or type names and avoid too cryptic abbreviations. I don't
think it's worth changing everything now though.
> +struct d3dx_preshader
> +{
> + struct d3dx_regstore regs;
> +
> + unsigned int ins_count;
> + struct d3dx_pres_ins *ins;
> +
> + struct d3dx_const_tab inputs;
> +};
> +
> +
> +struct d3dx_param_eval
That double empty line seems unnecessary.
> -HRESULT d3dx_create_param_eval(struct d3dx9_base_effect *base_effect, void *byte_code, unsigned int byte_code_size,
> +enum pres_ops
> +{
> + PRESHADER_OP_NOP,
> + PRESHADER_OP_MOV,
> + PRESHADER_OP_MAX_ENUM
> +};
Maybe rename _MAX_ENUM to _UNKNOWN? At least for this patch series you
don't really need that enum value though (see below).
> +static HRESULT regstore_alloc_table(struct d3dx_regstore *rs, unsigned int table)
> +{
> + unsigned int size;
> +
> + size = rs->table_sizes[table] * table_info[table].reg_component_count * table_info[table].component_size;
> + if (size)
> + {
> + rs->tables[table] = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size);
> + rs->table_value_set[table] = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
> + sizeof(*rs->table_value_set[table]) *
> + ((rs->table_sizes[table] + PRES_BITMASK_BLOCK_SIZE - 1) / PRES_BITMASK_BLOCK_SIZE));
Indentation.
> +static void regstore_set_values(struct d3dx_regstore *rs, unsigned int table, void *data,
> + unsigned int start_offset, unsigned int count)
> +{
> + unsigned int block_idx, start, end, start_block, end_block;
> +
> + if (!count)
> + return;
> +
> + memcpy((BYTE *)rs->tables[table] + start_offset * table_info[table].component_size,
> + data, count * table_info[table].component_size);
Indentation.
> + for (i = 0; i < PRESHADER_OP_MAX_ENUM; ++i)
> + if (ins_code == pres_op_info[i].opcode)
> + break;
> + if (i == PRESHADER_OP_MAX_ENUM)
> + {
> + FIXME("Unknown opcode %#x, raw %#x.\n", ins_code, ins_raw);
> + return NULL;
> + }
I'd use ARRAY_SIZE(pres_op_info) instead of PRESHADER_OP_MAX_ENUM.
> + cdesc = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*cdesc) * desc.Constants);
> + inputs_param = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*inputs_param) * desc.Constants);
AFAICS neither really needs HEAP_ZERO_MEMORY.
You should also check those allocations and bail out if either one fails.
> +static void update_table_sizes_consts(unsigned int *table_sizes, struct d3dx_const_tab *ctab)
> +{
> + unsigned int i, table, max_register;
> +
> + for (i = 0; i < ctab->input_count; ++i)
> + {
> + max_register = ctab->inputs[i].RegisterIndex + ctab->inputs[i].RegisterCount;
> + table = ctab->regset2table[ctab->inputs[i].RegisterSet];
> + if (table < PRES_REGTAB_COUNT)
> + table_sizes[table] = max(table_sizes[table], max_register);
> + }
> +}
> +
> +static void update_table_size(unsigned int *table_sizes, unsigned int table, unsigned int offset)
> +{
> + table_sizes[table] = max(table_sizes[table], get_reg_offset(table, offset) + 1);
> +}
Why not use it also in update_table_sizes_consts()? The "table <
PRES_REGTAB_COUNT" check should then go into the update_table_size()
helper.
> + if (const_count > UINT_MAX / sizeof(double))
> + {
> + WARN("Invalid immediate constants count %u.\n", const_count);
> + return NULL;
> + }
> + if (p - ptr + const_count * (sizeof(double) / sizeof(unsigned int)) >= count)
> + {
> + WARN("Byte code buffer ends unexpectedly.\n");
> + return NULL;
> + }
The first check seems unnecessary, if the idea was to avoid integer
overflows in the second check you can rewrite that one instead (e.g.
by dividing by sizeof(unsigned int) both sides of the inequality).
That second check can probably be improved by verifying that the
constants fit into the CLIT comment instead (see below).
BTW, the function return type is HRESULT, those returns generate
warnings for me.
> + pres->ins = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*pres->ins) * pres->ins_count);
You should probably check this allocation too.
> + for (i = 0; i < pres->ins_count; ++i)
> + {
> + unsigned int *ptr_next;
> +
> + ptr_next = parse_pres_ins(p, count, &pres->ins[i]);
> + if (!ptr_next)
> + return D3DXERR_INVALIDDATA;
> + count -= ptr_next - p;
> + p = ptr_next;
> + }
> +
> + if (!count)
> + {
> + WARN("Byte code buffer ends unexpectedly.\n");
> + return D3DXERR_INVALIDDATA;
> + }
These kinds of size checks probably work but they are somewhat hard to
follow. You could instead check the size of each comment section
(making sure that it doesn't overflow the whole bytecode buffer) and
then check that you don't go outside of each comment while parsing it.
find_bytecode_comment() could do the first check before returning and,
for example, also return the comment size so that the caller can use
it to validate the relevant accesses.
Hopefully what I mean is clear enough, otherwise as usual feel free to ask.
> +err_out:
> + FIXME("Error creating parameter evaluator.\n");
> + d3dx_free_param_eval(peval);
> *peval_out = NULL;
> - return E_NOTIMPL;
> + return;
> +}
That return is now unnecessary.