December 2013 - Wine-Devel - list.winehq.org

Re: ldd for wine dll

by Nikolay Sivov

On 12/21/2013 15:12, 逸天不羁 wrote: > hell every one, > I have write a application just like ldd of GNU/Linux, I don't how to > push it to the upstream. Here is the patchs. There are issues in your code that make it unacceptable for wine, such as using C++, But the most important thing is that I don't think wine needs such program at all, since winedump is able to dump imports already.

Dec. 21, 2013

Fwd: ldd for wine dll

by David Quintana (gigaherz)

(forwarding to the list) ---------- Forwarded message ---------- From: David Quintana (gigaherz) <gigaherz(a)gmail.com> Date: 21 December 2013 12:16 Subject: Re: ldd for wine dll To: 逸天不羁 <yitianbuji(a)qq.com> Read this guide: http://wiki.winehq.org/SubmittingPatches On 21 December 2013 12:12, 逸天不羁 <yitianbuji(a)qq.com> wrote: > hell every one, > I have write a application just like ldd of GNU/Linux, I don't how to push > it to the upstream. Here is the patchs. > > > >

Dec. 21, 2013

ldd for wine dll- Sorry for preview spell errors,

by 逸天不羁

hello every one, I have write a application just like ldd of GNU/Linux, I don't how to push it to the upstream. Here is the patchs.

Dec. 21, 2013

ldd for wine dll

by 逸天不羁

hell every one, I have write a application just like ldd of GNU/Linux, I don't how to push it to the upstream. Here is the patchs.

Dec. 21, 2013

Re: [3/5] ntdll: Allow passing NULL buffer to printf functions

by Alexandre Julliard

Sebastian Lackner <sebastian(a)fds-team.de> writes: > @@ -72,7 +73,12 @@ static inline int pf_output_stringW( pf_output *out, LPCWSTR str, int len ) > > if( len < 0 ) > len = strlenW( str ); > - if( out->unicode ) > + if (!out->buf.X) > + { > + out->used += len; > + return len; > + } > + else if (out->unicode) That's not correct for Unicode conversions. -- Alexandre Julliard julliard(a)winehq.org

Dec. 20, 2013

Re: wtsapi32: partial implementation of WTSEnumerateProcessesW (resend)

by André Hentschel

> diff --git a/dlls/wtsapi32/wtsapi32.c b/dlls/wtsapi32/wtsapi32.c > index 898b95d..53c6325 100644 > --- a/dlls/wtsapi32/wtsapi32.c > +++ b/dlls/wtsapi32/wtsapi32.c > @@ -18,9 +18,13 @@ > #include "config.h" > #include <stdarg.h> > #include <stdlib.h> > -#include "windef.h" > -#include "winbase.h" > +#include "ntstatus.h" > +#define WIN32_NO_STATUS > +#include "winternl.h" > #include "wtsapi32.h" > +#include "wine/library.h" > +#include "wine/server.h" > +#include "wine/unicode.h" > #include "wine/debug.h" do you need that all? > WINE_DEFAULT_DEBUG_CHANNEL(wtsapi); > @@ -84,14 +88,65 @@ BOOL WINAPI WTSEnumerateProcessesA(HANDLE hServer, DWORD Reserved, DWORD Version > BOOL WINAPI WTSEnumerateProcessesW(HANDLE hServer, DWORD Reserved, DWORD Version, > PWTS_PROCESS_INFOW* ppProcessInfo, DWORD* pCount) > { > - FIXME("Stub %p 0x%08x 0x%08x %p %p\n", hServer, Reserved, Version, > - ppProcessInfo, pCount); > + SYSTEM_PROCESS_INFORMATION *spi; > + ULONG size = 0x4000; > + void *buf = NULL; > + NTSTATUS status; > + DWORD i,lcount = 0; > + WTS_PROCESS_INFOW *linfo; can't you use sizeof(*spi) or a multiple of it for size? or clean it up somehow else... > if (!ppProcessInfo || !pCount) return FALSE; > > *pCount = 0; > *ppProcessInfo = NULL; > > + if (hServer != WTS_CURRENT_SERVER_HANDLE) > + { > + FIXME("Only WTS_CURRENT_SERVER_HANDLE is impemented\n"); > + return FALSE; > + } > + > + do { > + size *= 2; > + HeapFree(GetProcessHeap(), 0, buf); > + buf = HeapAlloc(GetProcessHeap(), 0, size); > + if (!buf) > + return FALSE; > + > + status = NtQuerySystemInformation(SystemProcessInformation, buf, size, NULL); > + } while(status == STATUS_INFO_LENGTH_MISMATCH); > + > + if (status != STATUS_SUCCESS) > + { > + HeapFree(GetProcessHeap(), 0, buf); > + SetLastError(RtlNtStatusToDosError(status)); > + return FALSE; > + } > + > + spi = buf; why not dropping buf completely? > + do { > + lcount++; > + spi = (SYSTEM_PROCESS_INFORMATION *)(((PCHAR)spi) + spi->NextEntryOffset); > + } while(spi->NextEntryOffset != 0); isn't there an easier way to get the count? > + linfo = HeapAlloc(GetProcessHeap(), 0, lcount * sizeof(WTS_PROCESS_INFOW)); > + if(!linfo) > + return FALSE; > + > + for(i = 0, spi = buf; i < lcount; i++) > + { > + linfo[i].SessionId = 0; > + linfo[i].ProcessId = HandleToUlong(spi->UniqueProcessId); > + linfo[i].pProcessName = spi->ProcessName.Buffer; > + linfo[i].pUserSid = NULL; > + spi = (SYSTEM_PROCESS_INFORMATION *)(((PCHAR)spi) + spi->NextEntryOffset); > + } > + *ppProcessInfo = linfo; > + *pCount = lcount; > + FIXME("pUserSid not filled\n"); > + > + HeapFree(GetProcessHeap(), 0, buf); > return TRUE; > } > > diff --git a/include/wtsapi32.h b/include/wtsapi32.h > index f4bab56..0476478 100644 > --- a/include/wtsapi32.h > +++ b/include/wtsapi32.h > @@ -135,6 +135,8 @@ typedef struct _WTS_SERVER_INFOW > DECL_WINELIB_TYPE_AW(WTS_SERVER_INFO) > DECL_WINELIB_TYPE_AW(PWTS_SERVER_INFO) > > +#define WTS_CURRENT_SERVER_HANDLE NULL > + maybe some more WTS_ defines while you're at it > void WINAPI WTSCloseServer(HANDLE); > BOOL WINAPI WTSConnectSessionA(ULONG, ULONG, PSTR, BOOL); > BOOL WINAPI WTSConnectSessionW(ULONG, ULONG, PWSTR, BOOL); >

Dec. 19, 2013

Re: [PATCH 1/3] port: MSVC provides a correct getenv prototype.

by Stefan Dösinger

Am 19.12.2013 um 15:23 schrieb Jonas Maebe <jonas.maebe(a)elis.ugent.be>: > Shouldn't the title of this patch read "getopt" instead of "getenv"? Uh, now that you mention it, the title isn’t quite right. It should be more like "port: MSVC does not provide a conflicting getopt prototype." - It doesn’t provide a getopt prototype at all. The stdlib.h include is needed for getenv, which is used in the file. I misread the "getopt" in the comment as "getenv" on my quick read. (And yes, I did wonder how this code is supposed to work without defining getenv at all, but my conclusion was that maybe a warning about undefined getenv was considered better than a compile error. It makes a lot more sense with a conflicting getopt.) I took the liberty to CC wine-devel on my reply.

Dec. 19, 2013

Re: taskschd: Add new dll.

by Saulius Krasuckas

* On Wed, 18 Dec 2013, Michael Stefaniuc wrote: > Saulius, > > > Could you please tell what app does need it? > > I find zero bugs with the bugzilla query. [*] > > I guess this is just personal interest as a "bugzilla entry" is not > needed to commit such a patch. Absolutely. I had trouble finding such applications on my own. But by googling in different, not so strightforward way I found five probable candidates: * Solar Winds Sftp Server * Photoshop CS6 and CC * Garena * Word of Warcraft * Symantec Service Framework (and native Explorer.exe from some Windows, of course) Quite a plenty;) Thanks anyway, S.

Dec. 18, 2013

Re: Wine + ICC (Intel XE Compiler)

by jordan

Hi Stefan > Your mail doesn’t suggest that you’re deliberately trying to build a 64 bit Wine. I haven’t tried icc myself, but I guess it should work for 32 bit Wine just as it did in 2008. I wasn't trying to explicitly (and only) build wine64... my build script just builds wine64 first, then 32bit wine next. > Note that a 64 bit Wine is only useful for running 64 bit Windows applications. It won’t magically run 32 bit applications with 64 bit only Linux libs. The most common way to use a 64 bit wine is together with a 32 bit build to form a WoW64 environment that runs both 32 bit and 64 bit windows apps. oh, i know the drill, Stefan. ~ All of my Wine prefixes are (mixed) 32bit/64bit, but i happen to mainly use 64bit Wine + WIN64 applications. For me, 32bit only comes into play when i have no choice but to use a 32bit app. (ie: i do have a few synth plugins that only work/available as 32bit... but that is far and few inbetween). btw, fantastic job on the command stream stuff. cheerz

Dec. 18, 2013

Re: taskschd: Add new dll.

by Michael Stefaniuc

Saulius, On 12/18/2013 11:15 AM, Saulius Krasuckas wrote: > * On Tue, 17 Dec 2013, Dmitry Timoshkov wrote: > >> 4 files changed, 123 insertions(+) >> create mode 100644 dlls/taskschd/Makefile.in >> create mode 100644 dlls/taskschd/taskschd.c >> create mode 100644 dlls/taskschd/taskschd.spec > > Could you please tell what app does need it? > I find zero bugs with the bugzilla query. [*] I guess this is just personal interest as a "bugzilla entry" is not needed to commit such a patch. > > S. > > [*] http://bugs.winehq.org/buglist.cgi?query_format=advanced&longdesc=taskschd&… > > bye michael

Dec. 18, 2013