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/
Hi guys,
Rather a peripheral question; apologies for that - but I'd imagine
there are experts here that may be able to help.
I have a black-box problem - a Windows app dealing with confidential
data that I can't easily touch (and thus can't get to run under Wine) -
which does some small but critical automation of MS Office - using VBS /
COM scripting.
I'd -really- love some input on how best to trace that series of COM
method calls on Windows itself ie. the (remote) service activation, and
the RPC beyond that - particularly the method names, parameters etc. of
the COM/OLE Office API. I've tried (so far):
http://www.rohitab.com/apimonitor
which, while closed, looks interesting; but traces a lot
in a hard-to-search way and doesn't appear to do the
trick.
https://support.microsoft.com/en-us/help/926098/how-to-enable-com-and-com-d…
Sounds useful: using Event Tracing for Windows (ETW) but
has this rather unhelpful property:
"The binary file must be formatted by Microsoft
so that it can be analyzed. Please forward the
.etl files to your support contact. ..." ;-)
Component models used to be all the rage in my youth ;-) surely someone
solved the "strace for COM calls" problem elegantly some-when !
Crazily - might it be possible to instrument, interpose and use Wine's
COM impl. on Windows [ which sounds a bit 'exciting' ;-], or ?
Anyhow - help much appreciated & sorry for the noise !
Regards,
Michael.
--
michael.meeks(a)collabora.com <><, Pseudo Engineer, itinerant idiot
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
Am 14.08.2017 um 12:35 schrieb Martin Storsjo:
> Windows uses a different ABI for va_list on arm64 just like on x86_64.
>
> On x86_64, the calling convention for windows functions is completely
> different from the one on other platforms. On arm64, they're mostly the
> same, with the only exception being variadic functions (where all float
> arguments are passed in integer registers, since the va_list is a single
> pointer).
>
> Any functions using __builtin_ms_va_start need to be decorated with
> __attribute__((ms_abi)).
>
> Add a check in configure for the support of __builtin_ms_va_list
> (both features appared in clang at the same time, in the 5.0 release).
>
> This fixes running binaries that use e.g. printf style functions
> (e.g. midl.exe from the windows 10 sdk), fixing
> https://bugs.winehq.org/show_bug.cgi?id=38886.
>
> Signed-off-by: Martin Storsjo <martin(a)martin.st>
> ---
> clang 5.0, which this requires, isn't yet released, but is in RC2 and
> will probably be released pretty soon.
> ---
> configure.ac | 7 +++++++
> include/msvcrt/crtdefs.h | 6 +++++-
> include/windef.h | 6 +++++-
> include/wine/test.h | 4 ++--
> 4 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 7d52b24..c33221f 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -179,6 +179,13 @@ case $host in
> CFLAGS="$CFLAGS -marm"
> AC_SUBST(TARGETFLAGS,"-marm")
> ;;
> + aarch64*)
> + AC_MSG_CHECKING([whether $CC supports __builtin_ms_va_list])
> + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <stdarg.h>]], [[void func(__builtin_ms_va_list *args);]])],
> + [AC_MSG_RESULT([yes])],
> + [AC_MSG_RESULT([no])
> + AC_MSG_ERROR([You need clang >= 5.0 to build Wine for arm64.])])
Hi,
The upstreamed variadic function handling is terrific, thanks for that!
I also like this patch as logical next step, I'm just a bit worried because it locks out current builds without upgrading to an RC...
At the moment I'm doing winelib builds with gcc for Linux/ARM64 and clang builds for Android/ARM64.
It's quite easy on Linux to pick up a new clang version, not sure how long it takes until clang5 is picked up in the Android NDK...
On the other hand, there are not much people building Wine for ARM64, and those can pretty easily revert your patch until they are at clang5
OK... We need this improvement, I'll sign it off :)
Now, we only need to convince distributions to avoid x18
On Wed, Sep 20, 2017 at 02:54:21PM +0300, Dmitry Timoshkov wrote:
> This looks like a typo, and this patch makes saving data in a pretty complex
> application work.
>
> Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru>
> ---
> dlls/ole32/datacache.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dlls/ole32/datacache.c b/dlls/ole32/datacache.c
> index 4e684b4189..c3383176f8 100644
> --- a/dlls/ole32/datacache.c
> +++ b/dlls/ole32/datacache.c
> @@ -1663,7 +1663,7 @@ static HRESULT WINAPI DataCache_Save(
> }
>
> /* this is a shortcut if nothing changed */
> - if (!dirty && !fSameAsLoad && This->presentationStorage)
> + if (!dirty && fSameAsLoad && This->presentationStorage)
> {
> return IStorage_CopyTo(This->presentationStorage, 0, NULL, NULL, pStg);
> }
No, this isn't a typo. The idea is to copy the loaded storage to a
fresh storage that is passed when fSameAsLoad is FALSE.
I'm aware that there are issues related to the storage handling
in both the cache and the default handler. That's on my list
of things to look into, but feel free to investigate further.
Huw.
Hello, the current WINE logo is really ugly in highest level! and has
no concept, please change it with better one, I have a good sample:
https://commons.wikimedia.org/wiki/File:Wine_bw.png
It is really beautiful and Window$ logo shows its relationship with M$
Windows, I hope this logo is legal.
.
Hello!
So all the way back at wineconf I volunteered to be swag master for winehq. The idea is to have something that can be given away at trade shows, presentations, LUG visits and the like. Just something to help promote the visibility of the project.
Jana here, CodeWeavers marketing director, has put together a sampling of designs to do as our first sticker and so now we are looking for some feedback on what people prefer.
https://docs.google.com/forms/d/e/1FAIpQLSd5X_fXe9KSFAppRHz8kUo3XKeODyH5KeX…
Rosanne? Could you direct me as to where this should be put up for the users as well? I am unfamiliar with how to communicate to our user base.
The poll will run for as long as it feels like it needs to get some sort of winner. Comments and suggestions are always welcome!
-aric
2017-09-23 22:52 GMT+02:00 Fabian Maurer <dark.shadow4(a)web.de>:
> When no midi port or only the midi-through port
> is found, we can inform the user that midi
> won't work as expected.
>
> Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de>
> ---
> dlls/midimap/midimap.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/dlls/midimap/midimap.c b/dlls/midimap/midimap.c
> index 64b4dc8546..c80834515b 100644
> --- a/dlls/midimap/midimap.c
> +++ b/dlls/midimap/midimap.c
> @@ -553,6 +553,7 @@ static LRESULT MIDIMAP_drvOpen(void)
> {
> MIDIOUTCAPSW moc;
> unsigned dev, i;
> + WCHAR throughportW[] = {'M','i','d','i',' ','T','h','r','o','u','g','h',0};
>
> if (midiOutPorts)
> return 0;
> @@ -578,6 +579,13 @@ static LRESULT MIDIMAP_drvOpen(void)
> }
> }
>
> + if(numMidiOutPorts == 0)
> + MESSAGE("Midi sound output won't work - No midi port found.\n");
> + else if(numMidiOutPorts == 1 && midiOutPorts[0].loaded == -1)
> + MESSAGE("Midi sound output won't work - No working midi port found.\n");
> + else if(numMidiOutPorts == 1 && strncmpW(midiOutPorts[0].name, throughportW, strlenW(throughportW)) == 0)
> + MESSAGE("Midi sound output probably won't work - Only 'midi through' port found. Make sure your setup is correct.\n");
> +
> return 1;
> }
Since you have to resend anyway...
The string comparison doesn't look correct to me, I think that breaks
if the midi port name has a prefix matching the throughportW string. I
guess it's not going to be a problem in practice but it seems better
to do it right anyway.
There should be a space between 'if' and the '(', like elsewhere in
the function and source file.