Re: Patch for bug 34388
On Sep 6, 2013, at 5:01 PM, Juan Lang wrote: > On Fri, Sep 6, 2013 at 3:54 PM, Charles Davis wrote: > Maybe then the real fix is to make Wine accept either a constructor SET or > the custom tag (ASN_CONTEXT | ASN_CONSTRUCTOR) it currently accepts, for > either attribute set. I should come up with a test case first, though, to see > if that's what Windows does. I'll get back to you on that. > > Yeah, that seems plausible, as either some sort of BER/DER thing or just two > alternate encodings for the same value. I'm not certain, but tests will > definitely help. So much for that theory. I tried twice to replace the CONSTRUCTOR | CONTEXT tag with the generic CONSTRUCTOR | SET tag (jobs 2057 and 2058 on newtestbot). Both times, Crypto bailed out. I don't think Windows will accept a CONSTRUCTOR | SET tag there under any circumstances. I think we're seriously screwing up somewhere reading the code signature. Trouble is, I don't know where, or if this is even a problem in Wine at all--it might be peculiar to my system. (The other Wine users who reported being unable to run the Star Citizen Launcher because of this were missing a root CA.) I don't know why, but strangely, the problem with the Launcher that prompted my patch seems to have gone away (at least, on my system) with the update they just released. Maybe it's related to the problems a few people were having with this on Windows. Maybe the signature really was malformed. Chip
Re: Patch for bug 34388
y tests too. Sigh. Sorry > about that. Could you add that and see what that turns up? I did what you said, and it turns out that my initial analysis (if you can call it that) was wrong. Windows Crypto doesn't accept the SET either way (cf. job 2056 on newtestbot). In the "AuthAttrsAndUnknownItem" case, it might be because it already encountered the AuthAttrs set and didn't expect to find another one. But I suspect that in the other case (just with the "UnknownItem"), it's because Crypto was expecting to find something in the set, but didn't. (I did, after all, fill the set with zeroes.) Maybe then the real fix is to make Wine accept either a constructor SET or the custom tag (ASN_CONTEXT | ASN_CONSTRUCTOR) it currently accepts, for either attribute set. I should come up with a test case first, though, to see if that's what Windows does. I'll get back to you on that. Chip > --Juan > > > On Thu, Sep 5, 2013 at 11:57 PM, Charles Davis wrote: > Hi Juan, > > I need some advice. > > Attached is a patch to fix bug 34388, where an app that tries to verify its > code signature fails because Wine, while parsing the certificates embedded > within the signature, encounters an item in the CMS signer info (tag 0x31, > i.e. ASN_UNIVERSAL | ASN_CONSTRUCTOR | 0x11), right before the > HashEncryptionAlgorithm sequence item, that it doesn't yet know how to > decode. This patch (which just skips the item in question) allows that app to > successfully verify its code signature and run, but... > > My testing on Windows (cf. job 2037 on newtestbot) shows some interesting > behavior. Windows will indeed accept this item, but only if the AuthAttrs > item is also present and immediately precedes it in the sequence. (The other > test bails out with CRYPT_E_ASN_BADTAG.) I don't quite know what to make of > this. The odd thing is that the certificate in question doesn't have this > optional AuthAttrs item, and yet (in most cases, at least) most people who > run this particular app on Windows do not have this problem. I can't seem to > find anything about this from reading the relevant RFCs. Is there something > I'm missing? > > Thanks. > > Chip >
Patch for bug 34388
Hi Juan, I need some advice. Attached is a patch to fix bug 34388, where an app that tries to verify its code signature fails because Wine, while parsing the certificates embedded within the signature, encounters an item in the CMS signer info (tag 0x31, i.e. ASN_UNIVERSAL | ASN_CONSTRUCTOR | 0x11), right before the HashEncryptionAlgorithm sequence item, that it doesn't yet know how to decode. This patch (which just skips the item in question) allows that app to successfully verify its code signature and run, but... My testing on Windows (cf. job 2037 on newtestbot) shows some interesting behavior. Windows will indeed accept this item, but only if the AuthAttrs item is also present and immediately precedes it in the sequence. (The other test bails out with CRYPT_E_ASN_BADTAG.) I don't quite know what to make of this. The odd thing is that the certificate in question doesn't have this optional AuthAttrs item, and yet (in most cases, at least) most people who run this particular app on Windows do not have this problem. I can't seem to find anything about this from reading the relevant RFCs. Is there something I'm missing? Thanks. Chip 0001-crypt32-Skip-unknown-item-when-decoding-a-CMS-certif.patch Description: Binary data
Re: ws2_32: Implement get socket option SO_PROTOCOL_INFO (try 2)
On Sep 3, 2013, at 1:30 PM, Bruno Jesus wrote: > On Tue, Sep 3, 2013 at 4:26 PM, Charles Davis wrote: >>> You mean removing protocol.c and adding all content to socket.c? If >>> yes I would appreciate if you could do that because I don't have the >>> git skills and wouldn't now how to sort the functions inside socket.c. >> It's not that hard. Just copy all the substantial stuff from protocol.c >> into socket.c, and then you can run: >> >> $ git rm --force protocol.c >> $ git commit --amend socket.c protocol.c # apply changes to your existing >> commit > > Thanks, but what about makefiles and automake stuff? automake? Wine doesn't use automake. As for the makefiles, just look in dlls/ws2_32/Makefile.in for the line: C_SRCS = \ async.c \ protocol.c \ socket.c and remove the reference to protocol.c. Chip > >> Chip > > > Regards, > Bruno
Re: ws2_32: Implement get socket option SO_PROTOCOL_INFO (try 2)
On Sep 3, 2013, at 12:37 PM, Bruno Jesus wrote: > On Tue, Sep 3, 2013 at 3:34 PM, Alexandre Julliard > wrote: >> Bruno Jesus <00cp...@gmail.com> writes: >> >>> On Tue, Sep 3, 2013 at 3:16 PM, Bruno Jesus <00cp...@gmail.com> wrote: On Tue, Sep 3, 2013 at 3:04 PM, Alexandre Julliard wrote: > Bruno Jesus <00cp...@gmail.com> writes: > >> try 2: >> Narrow the loop for the specified protocol >> Add a new test for invalid sockets > > Considering what WSAEnumProtocols does, the loop doesn't seem necessary > at all. It will when WSAEnumProtocols return AF_INET6 data =) >>> >>> Will you find more reasonable to "unstatic" >>> WINSOCK_EnterSingleProtocolW from protocol.c, add a family parameter >>> to it and use it inside socket.c ? >> >> Yes, though moving it all to socket.c is probably cleaner. We don't need >> a separate file for just that one API. > > You mean removing protocol.c and adding all content to socket.c? If > yes I would appreciate if you could do that because I don't have the > git skills and wouldn't now how to sort the functions inside socket.c. It's not that hard. Just copy all the substantial stuff from protocol.c into socket.c, and then you can run: $ git rm --force protocol.c $ git commit --amend socket.c protocol.c # apply changes to your existing commit Chip
Re: Help to create a server request
On Aug 29, 2013, at 6:43 PM, Bruno Jesus wrote:
> Hi all, I need some help to continue my current wine work.
>
> In order to implement SO_PROTOCOL_INFO for getsockopt I need to
> retrieve some information from the socket like its family and
> protocol.
>
> I have searched for a few days and ended up with a solution I dislike
> so I had a better idea (at least I hope I did).
>
> Instead of using non-portable SO_DOMAIN and SO_PROTOCOL/SO_PROTOTYPE
> to retrieve the socket family and protocol or using non-reliable
> guessing using only the socket type I thought it would be better to
> ask the server for this information. Using a request just like is used
> for several other information in ws2_32 (operation which will work on
> every OS).
>
> So, all I need is a server request that based on the socket fd will
> return the socket family, type and protocol. I tried to understand how
> requests work but I failed completely.
>
> Maybe this request can be later improved to return the connection time
> so we can finally fix SO_CONNECT_TIME option.
>
> The current solution is attached, since I sent the tests separated and
> they were commited the patch will not apply, it's only for reference.
> The idea is to remove the functions get_sock_[family|protocol|type] to
> a single server request.
>
> So, is this a good idea?
There's no way I know of to get this information directly on at least Mac OS,
so I'd say go for it. (But I can't speak for anyone else on this list, so...)
> If yes, how can I create and use the request?
To add a new request to the server, you first add a definition to
server/protocol.def . This file is processed by the make_requests tool, which
generates a bunch of other files from it. The syntax of the server protocol
definition file is somewhat like Objective-C (if you've ever used or seen
that). A typical server request definition looks like this:
@REQ(request_name)
/* input parameters go here */
int input;
obj_handle_t handle; /* don't use Windows types */
@REPLY
/* output values go here */
int output;
@END
As with all generated files, the files generated by make_requests shouldn't be
included in your patch.
After defining a new server call, you define the handler in the server like so:
DECL_HANDLER(request_name)
{
/* implicit parameters: req, reply */
/* use the 'current' global to refer to the process and thread that made
the request */
if (req->handle != ((obj_handle_t)-1))
{
reply->output = do_something(req->input, req->handle);
}
else
{
set_error(STATUS_UNSUCCESSFUL); /* NTSTATUS is returned to client */
}
/* no return value */
}
Then, in the client DLLs, you make server calls like this:
SERVER_START_REQ( request_name )
{
/* implicit variables: req, reply */
req->input = 1;
req->handle = wine_server_obj_handle( handle ); /* converts Windows HANDLE
to a server obj_handle_t */
if (wine_server_call( req ) != STATUS_SUCCESS)
{
/* SetLastError(), return error code, etc. */
}
do_something(reply->output);
}
SERVER_END_REQ;
There's lots of examples throughout Wine of this in action, especially in
lower-level DLLs like ntdll and kernel32; I encourage you to look at them.
(That's how I figured all this out, after all.) If you have any more questions
(and not just because you were too lazy to even look ;), feel free to ask.
Chip
Re: RFC: Mark dylib/mach-o on Mac OS X
On Aug 29, 2013, at 2:35 PM, André Hentschel wrote:
> Am 29.08.2013 19:52, schrieb André Hentschel:
>> Hi,
>> thank you both for the comments, i'll see what i can do.
>
> How about that?
Much better, but...
>
> diff --git a/programs/winedbg/info.c b/programs/winedbg/info.c
> index c0b86ba..0667ad7 100644
> --- a/programs/winedbg/info.c
> +++ b/programs/winedbg/info.c
> @@ -244,6 +244,11 @@ void info_win32_module(DWORD64 base)
> }
> }
> }
> +else if (strstr(im.mi[i].ModuleName, ""))
> +{
> +dbg_printf("Mach-O\t");
> +module_print_info(&im.mi[i], FALSE);
If there are any modules embedded in a Mach-O file (i.e. the PE DLLs embedded
in a Wine built-in DLL), this will no longer print them.
> +}
> else
> {
> /* check module is not embedded in another module */
Chip
Re: patch:kernel32
On Aug 29, 2013, at 8:15 AM, matyapiro31 wrote: > > <0001-kernel32-change-for-loop-to-optimize.patch><0002-kernel32-change-for-loop-to-optimize.patch> One patch per email, please. Also, the subject should be more descriptive. The first one doesn't look much better than the second one (which was already rejected). sizeof(array)/sizeof(array[0]) is a constant expression; any optimizing compiler worth its salt will optimize that for you. (And I would know, because I work on LLVM and Clang.) The first part of that patch (against dlls/kernel32/console.c) might be a bit more promising, though, since it hoists a computation that isn't constant at compile time but is constant for the duration of the loop; but again, any good optimizing compiler would be smart enough to do that, too. Oh, and you forgot to actually declare the variables that hold the hoisted values. Those assignments don't count, because: a) You never gave them a type. That's an error in any C compiler (C89, C99, etc.) I'm not even sure a K&R compiler would take that. b) Wine is written in C89 (with some GNU extensions scattered throughout, but generally we try to write portable code around here); that means (among other things) all variable declarations must come before other statements. Did you even try to compile Wine with these patches? Chip
Re: RFC: Mark dylib/mach-o on Mac OS X
On Aug 27, 2013, at 3:08 PM, André Hentschel wrote:
> Hi,
> at [1] i noticed that dylibs are printed as PEs.
> This intents to fix that, but i have no Mac, could someone please review/test?
>
> [1]
> http://test.winehq.org/data/8ef3a142263e6db11f1514f77b3de84c8b08d7a0/mac_fg-snow-macdrv/advapi32:cred.html
I generally agree with Ken's comments. In addition:
>
> diff --git a/dlls/dbghelp/module.c b/dlls/dbghelp/module.c
> index 6bea436..41fa7e6 100644
> --- a/dlls/dbghelp/module.c
> +++ b/dlls/dbghelp/module.c
> @@ -33,6 +33,7 @@
> WINE_DEFAULT_DEBUG_CHANNEL(dbghelp);
>
> const WCHARS_ElfW[] = {'<','e','l','f','>','\0'};
> +const WCHARS_MachoW[] = {'<','m','a','c','h','o','>','\0'};
Personally, I'd prefer:
const WCHARS_MachOW[] = {'<','m','a','c','h','-','o','>','\0'};
> diff --git a/programs/winedbg/info.c b/programs/winedbg/info.c
> index c0b86ba..c2c7c08 100644
> --- a/programs/winedbg/info.c
> +++ b/programs/winedbg/info.c
> @@ -253,8 +258,11 @@ void info_win32_module(DWORD64 base)
> break;
> }
> if (j < im.num_used) continue;
> -if (strstr(im.mi[i].ModuleName, ".so") ||
> strchr(im.mi[i].ModuleName, '<'))
> +if (strstr(im.mi[i].ModuleName, ".so") ||
> strstr(im.mi[i].ModuleName, "") ||
> +strstr(im.mi[i].ModuleName, ""))
The 'wine' binary (the module whose name is "") is a Mach-O file,
too, on Mac OS.
Chip
Re: [PATCH] winemac.drv: Support the public UTF-16 type for Unicode text.
On Aug 21, 2013, at 10:34 PM, Ken Thomases wrote:
> On Aug 21, 2013, at 9:42 PM, Charles Davis wrote:
>> +static HANDLE import_utf16_to_unicodetext(CFDataRef data)
>> +{
>> +const WCHAR *src;
>> +unsigned long data_len;
>> +unsigned long new_lines = 0;
>> +LPWSTR dst;
>> +unsigned long i, j;
>> +HANDLE unicode_handle = NULL;
>
> This is an unnecessary initialization / dead store, which is frowned upon.
I was only blindly copying the code that you wrote ;).
Chip
Re: [PATCH] winemac.drv: Use the public UTF-16 type for Unicode text.
On Aug 21, 2013, at 10:11 AM, Ken Thomases wrote: > On Aug 21, 2013, at 10:12 AM, Ken Thomases wrote: > >> On Aug 20, 2013, at 10:49 PM, Charles Davis wrote: >> >>> In the Windows world, "Unicode" almost universally means "UTF-16". So, >>> use the well-known UTF-16 type instead of making up our own. >>> >>> I have to wonder if there was a good reason Ken didn't use this >>> initially. >> >> Please hold this patch while I review it. >> >> I think there is a good reason why I didn't use it, but I have to figure it >> out again. :-/ >> >> It has to do with a promised pasteboard type (what Microsoft calls delayed >> rendering) and the conversions to the other text types. I think we need to >> use a custom type to distinguish between being asked for promised data vs. >> being asked for a conversion. > > Well, that wasn't the reason. However, I've found a simpler reason not to > commit this. The data supplied for CF_UNICODETEXT is null-terminated, but > public.utf16-plain-text shouldn't be. (Neither CFString nor NSString treat a > 0x code unit specially. It just ends up part of the string.) Wow, I didn't know that. I guess that makes sense, because NSCFStrings are counted. > > Was there a specific compatibility problem you were trying to solve? Or just > reviewing the code and found this strange and wanted to improve it? I was looking over the patches as you sent them, found this strange, and thought this would improve it. > > If you like, it may make sense to add conversions to public.utf16-plain-text > like those done for public.utf8-plain-text, but the import/export functions > will have to add/remove the terminating null. Sounds good. But it might take me a little while to rework this. I have a bunch of other things going on at the moment. I'll probably miss today's commit wave, but not tomorrow's. Chip
Re: Compiler warnings on Debian kfreebsd-i386
On Aug 9, 2013, at 11:01 AM, Ken Sharp wrote: > On 08/08/13 21:28, Charles Davis wrote: >> >> On Aug 8, 2013, at 8:20 AM, Ken Sharp wrote: >> >>> Some interesting, some not: >>> >>> /home/ken/wine-git/dlls/iphlpapi/ipstats.c:1898:24: warning: ‘get_pid_map’ >>> defined but not used [-Wunused-function] >>> /home/ken/wine-git/dlls/iphlpapi/ipstats.c:1953:21: warning: >>> ‘find_owning_pid’ defined but not used [-Wunused-function] >> I have a patch to fix those (and another one to fix them on Mac OS), but >> there's a bunch of patches ahead of it in my queue. Also, the patch was >> designed for standard FreeBSD (it needs libprocstat), so I'm not sure how >> well it will work on GNU/kFreeBSD. I've attached both patches so you can >> test it. N.B. the Mac OS patch needs to be applied first--it was developed >> first, and it implements the guts of the GetExtended*Table functions that >> actually call those functions. Also, you'll need to run autoreconf(1) after >> applying: the patches contain changes to configure.ac, but not configure or >> include/config.h.in. >> > > Unfortunately the build breaks with the two patches applied in Wine 1.7.0. > > winegcc: File does not exist: @LIBPROCSTAT@ Did you run autoreconf like I said? Chip
Re: Compiler warnings on Debian kfreebsd-i386
On Aug 8, 2013, at 8:20 AM, Ken Sharp wrote: > Some interesting, some not: > > /home/ken/wine-git/dlls/iphlpapi/ipstats.c:1898:24: warning: ‘get_pid_map’ > defined but not used [-Wunused-function] > /home/ken/wine-git/dlls/iphlpapi/ipstats.c:1953:21: warning: > ‘find_owning_pid’ defined but not used [-Wunused-function] I have a patch to fix those (and another one to fix them on Mac OS), but there's a bunch of patches ahead of it in my queue. Also, the patch was designed for standard FreeBSD (it needs libprocstat), so I'm not sure how well it will work on GNU/kFreeBSD. I've attached both patches so you can test it. N.B. the Mac OS patch needs to be applied first--it was developed first, and it implements the guts of the GetExtended*Table functions that actually call those functions. Also, you'll need to run autoreconf(1) after applying: the patches contain changes to configure.ac, but not configure or include/config.h.in. > /home/ken/wine-git/dlls/ntdll/directory.c: In function ‘wine_getdirentries’: > /home/ken/wine-git/dlls/ntdll/directory.c:1710:5: warning: passing argument 4 > of ‘getdirentries’ from incompatible pointer type [enabled by default] > In file included from /home/ken/wine-git/dlls/ntdll/directory.c:29:0: > /usr/include/dirent.h:313:18: note: expected ‘__off_t * __restrict__’ but > argument is of type ‘long int *’ This one has to do with the actual getdirentries(2) prototype: int getdirentries(int, char *, int, long *); glibc's prototype is broken. It really is a 'long *', not an 'off_t *' (don't believe me? Go read the syscalls.master file in the kernel source). Or, maybe they're aware of this, and glibc's getdirentries(2) stub extends the 32-bit long (on a 32-bit system) into an off_t--in which case, we'll need a configure check for this. Chip 0001-iphlpapi-Implement-find_owning_pid-for-Mac-OS.patch Description: Binary data 0002-iphlpapi-Implement-find_owning_pid-on-FreeBSD.patch Description: Binary data
Clang warns on "wrong" header guard in "config.h"
Hi, I've been building Wine with Clang, and it (apparently, unlike GCC) produces warnings like this: ../../include/config.h:4:9: warning: 'WINE_CROSSTEST' is used as a header guard here, followed by #define of a different macro [-Wheader-guard] #ifndef WINE_CROSSTEST ^~ ../../include/config.h:5:9: note: '__WINE_CONFIG_H' is defined here; did you mean 'WINE_CROSSTEST'? #define __WINE_CONFIG_H ^~~ WINE_CROSSTEST I tracked this down to these three lines in configure.ac: AH_TOP([#ifndef WINE_CROSSTEST #define __WINE_CONFIG_H]) AH_BOTTOM([#endif /* WINE_CROSSTEST */]) These lines generate what Clang thinks is the header guard for the "config.h" header, but we know that it isn't--that header AFAICT has never had an include guard, and __WINE_CONFIG_H is just there to indicate that it's been included. Should we change the __WINE_CONFIG_H macro to be a real header guard instead, or (as I'll admit it has been in the past) is Clang broken here? I'd imagine you guys don't want to rig configure to add -Wno-header-guard to CFLAGS if you can help it. I will point out that lots of these warnings are generated when building with Clang, because (for obvious reasons) this particular header is included all over the place. It makes it harder to see real warnings (like the ones that caused AJ not to commit my last two patches). And please don't tell me to use GCC instead. I suspect that GCC might pick up a similar warning--there's been lots of cross pollination going on between GCC and Clang, so we might have to deal with this sooner or later--and I'd prefer sooner. (I know the commit that added the WINE_CROSSTEST checks is from over 3 years ago, but this warning was only added recently to Clang, which is why I'm only bringing this up now.) Chip
Re: How to configure C++ implements in wine?
On Jul 15, 2013, at 1:00 AM, 中川祥 wrote: > I'm working at User Access Logging API for Windows8. > It need C++ style coding. > How can I solve it? Those aren't C++ classes. Those are MOF classes. They're used with WMI. I'm sure you've seen how we implement WMI (cf. dlls/wbemprox). They do not need to be written in C++. Chip
Re: api-ms-win-core-localregistry-l1-1-0: add stub dll
On Jun 4, 2013, at 12:15 PM, Austin English wrote: > diff --git > a/dlls/api-ms-win-core-localregistry-l1-1-0/api-ms-win-core-localregistry-l1-1-0.spec > > b/dlls/api-ms-win-core-localregistry-l1-1-0/api-ms-win-core-localregistry-l1-1-0.spec > new file mode 100644 > index 000..cc15d4e > --- /dev/null > +++ > b/dlls/api-ms-win-core-localregistry-l1-1-0/api-ms-win-core-localregistry-l1-1-0.spec > @@ -0,0 +1,40 @@ > +@ stub RegCloseKey Why don't you just forward them to their implementations in advapi32? Is there something oddly different about these functions that I don't know about? Chip
Re: [PATCH 2/5] dinput: Support SendForceFeedbackCommand for OSX joysticks
On May 21, 2013, at 1:34 PM, Andrew Eikum wrote:
> ---
> dlls/dinput/joystick_osx.c | 34 --
> 1 file changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/dlls/dinput/joystick_osx.c b/dlls/dinput/joystick_osx.c
> index 94398e7..8fb675d 100644
> --- a/dlls/dinput/joystick_osx.c
> +++ b/dlls/dinput/joystick_osx.c
> @@ -1135,6 +1135,36 @@ static HRESULT WINAPI
> JoystickAImpl_CreateEffect(IDirectInputDevice8A *iface,
> type, params, out, outer);
> }
>
> +static HRESULT WINAPI
> JoystickWImpl_SendForceFeedbackCommand(IDirectInputDevice8W *iface,
> +DWORD flags)
> +{
> +JoystickImpl *This = impl_from_IDirectInputDevice8W(iface);
> +HRESULT hr;
> +
> +TRACE("%p 0x%x\n", This, flags);
> +
> +if(!This->ff)
> +return DI_NOEFFECT;
> +
> +hr = FFDeviceSendForceFeedbackCommand(This->ff, flags);
> +if(FAILED(hr)){
> +WARN("FFDeviceSendForceFeedbackCommand failed: %08x\n", hr);
> +return hr;
You can't return the straight HRESULT from ForceFeedback here. That's because
the codes in the FACILITY_NULL range on Mac get their values from the 16-bit
COM runtime (cf. ). You must turn them into their
corresponding Win32 codes.
Chip
Re: windowscodecs: Add support for IMILBitmapSource interface.
On May 19, 2013, at 9:14 PM, Dmitry Timoshkov wrote:
> diff --git a/dlls/windowscodecs/bitmap.c b/dlls/windowscodecs/bitmap.c
> index f8904df..646f3a7 100644
> --- a/dlls/windowscodecs/bitmap.c
> +++ b/dlls/windowscodecs/bitmap.c
> @@ -446,6 +471,226 @@ static const IWICBitmapVtbl BitmapImpl_Vtbl = {
> BitmapImpl_SetResolution
> };
>
> +static HRESULT WINAPI IMILBitmapImpl_QueryInterface(IMILBitmapSource *iface,
> REFIID iid,
> +void **ppv)
> +{
> +BitmapImpl *This = impl_from_IMILBitmapSource(iface);
> +TRACE("(%p,%s,%p)\n", iface, debugstr_guid(iid), ppv);
> +
> +if (!ppv) return E_INVALIDARG;
> +
> +if (IsEqualIID(&IID_IUnknown, iid) ||
> +IsEqualIID(&IID_IMILBitmapSource, iid))
> +{
> +*ppv = &This->IMILBitmapSource_iface;
> +IUnknown_AddRef((IUnknown*)*ppv);
> +return S_OK;
> +}
You're violating COM rules here: when you QI an object for an interface
pointer, the QI must always return the same result no matter what. Here,
however, you're returning this interface pointer in response to a query for
IUnknown, when the already-existing QueryInterface method on the IWICBitmap
interface returns *itself* for IUnknown! Now when you QI for IUnknown on both
of these interfaces, they won't compare equal. (I suspect you're not convinced.
After all, native might violate COM rules here, too. I doubt that (see below),
but it might. So, write a test that QI's for IUnknown from both interfaces, and
checks if they're equal or not. Then we'll see who's right.)
> diff --git a/dlls/windowscodecs/wincodecs_private.h
> b/dlls/windowscodecs/wincodecs_private.h
> index dddb327..29f7726 100644
> --- a/dlls/windowscodecs/wincodecs_private.h
> +++ b/dlls/windowscodecs/wincodecs_private.h
> @@ -27,6 +27,46 @@ DEFINE_GUID(GUID_WineContainerFormatTga,
> 0x0c44fda1,0xa5c5,0x4298,0x96,0x85,0x47
>
> DEFINE_GUID(GUID_VendorWine,
> 0xddf46da1,0x7dc1,0x404e,0x98,0xf2,0xef,0xa4,0x8d,0xfc,0x95,0x0a);
>
> +DEFINE_GUID(IID_IMILBitmapSource,0x7543696a,0xbc8d,0x46b0,0x5f,0x81,0x8d,0x95,0x72,0x89,0x72,0xbe);
> +#define INTERFACE IMILBitmapSource
> +DECLARE_INTERFACE_(IMILBitmapSource,IUnknown)
> +{
> +/*** IUnknown methods ***/
> +STDMETHOD_(HRESULT,QueryInterface)(THIS_ REFIID,void **) PURE;
You know you can just use the STDMETHOD() macro (no trailing underscore), e.g.:
STDMETHOD(QueryInterface)(THIS_ REFIID,void **) PURE;
for methods that return an HRESULT, right? Or do you prefer explicitly
declaring the return type like that, even if it is more typing?
> +STDMETHOD_(ULONG,AddRef)(THIS) PURE;
> +STDMETHOD_(ULONG,Release)(THIS) PURE;
> +/*** IMILBitmapSource methods ***/
> +STDMETHOD_(HRESULT,GetSize)(THIS_ UINT *,UINT *);
> +STDMETHOD_(HRESULT,GetPixelFormat)(THIS_ int *);
> +STDMETHOD_(HRESULT,GetResolution)(THIS_ double *,double *);
> +STDMETHOD_(HRESULT,CopyPalette)(THIS_ IWICPalette *);
> +STDMETHOD_(HRESULT,CopyPixels)(THIS_ const WICRect *,UINT,UINT,BYTE *);
> +STDMETHOD_(HRESULT,UnknownMethod1)(THIS_ void **);
> +};
> +#undef INTERFACE
> +
> +#define INTERFACE IMILUnknown1
> +DECLARE_INTERFACE_(IMILUnknown1,IUnknown)
> +{
> +/*** IUnknown methods ***/
> +STDMETHOD_(HRESULT,QueryInterface)(THIS_ REFIID,void **) PURE;
> +STDMETHOD_(ULONG,AddRef)(THIS) PURE;
> +STDMETHOD_(ULONG,Release)(THIS) PURE;
> +};
> +#undef INTERFACE
Wouldn't that just make this interface a plain old IUnknown? Or does it have
its own IID? (Or does that not even matter, given that it's returned from that
"UnknownMethod1" above?) If it is nothing more than a plain IUnknown, why did
you even add this, since it doesn't really extend the IUnknown interface with
any new methods?
It's telling that its v-table is the very first v-table in the object. This
probably indicates that this really is the canonical IUnknown (i.e. the one
that gets returned when you QI for IUnknown), and the other interfaces'
IUnknown methods just delegate to this one. If I haven't missed my guess about
this object's QI implementation, then this is the IUnknown that should get
returned from a QI for IUnknown.
This might actually be an object that supports aggregation; you may want to
test for that, too ;).
Chip
Re: request.h: size of unnamed array is negative
On Apr 13, 2013, at 9:43 PM, Hugh McMaster wrote: > On Apr 13, 2013, at 7:39 AM, Hugh McMaster wrote: > >> I've been adding a new handler to Wine's server. Unfortunately, I've run >> into a problem with C_ASSERT that I can't seem to resolve. >> >> In server/request.h, I've added the following code: > STOP! You should modify server/protocol.def instead. The file you changed is > automatically generated from protocol.def, along with a bunch of other files > needed to make the server interface magic work. > > Hi Charles, > > I had already modified protocol.def. Oh. It's just that you hadn't mentioned that. Sorry for the curt "STOP" above. > The interesting thing about server/request.h is that the handler declarations > appear in the area of the file commented as automatically generated. Of course they do. The Perl script tools/make_requests is responsible for generating those declarations from server/protocol.def. It is also responsible for generating include/wine/server_protocol.h, and pieces of server/trace.c. You should not have to manually change any of them (other than protocol.def, of course). You might, however, have to run make_requests manually, though (the makefiles, for some reason, won't invoke it for you). Also, bear in mind that, when you're done with your patch and you submit it to wine-patches, you should not include the changes to any generated files (despite that they're version-controlled). Don't worry; AJ will run make_requests when he commits your patch to update the files in version control. Oh, and a warning: AJ is very touchy about the server (and why not? It's probably the most critical component in Wine, being responsible for coordinating all Wine processes in a given prefix). He holds patches against the server to much higher standards than usual--and they're already pretty high. So don't worry if your patch doesn't get in at first. Chip
Re: request.h: size of unnamed array is negative
On Apr 13, 2013, at 9:40 PM, Hugh McMaster wrote: > Am 13.04.2013 15:39, schrieb Hugh McMaster: >> I've been adding a new handler to Wine's server. Unfortunately, I've run >> into a problem with C_ASSERT that I can't seem to resolve. >> >> In server/request.h, I've added the following code: >> >> C_ASSERT( FIELD_OFFSET(struct get_desktop_workarea_request, spi_workarea) == >> 16 ); >> C_ASSERT( sizeof(struct get_desktop_workarea_request) == 16 ); >> C_ASSERT( FIELD_OFFSET(struct get_desktop_workarea_reply, screen_x) == 4 ); >> C_ASSERT( FIELD_OFFSET(struct get_desktop_workarea_reply, screen_y) == 4 ); >> C_ASSERT( sizeof(struct get_desktop_workarea_reply) == 8 ); >> >> But the compiler ends with output errors, as in the following: >> >> In file included from request.c:69:0: >> request.h:1527:1: error: size of unnamed array is negative >> request.h:1528:1: error: size of unnamed array is negative >> request.h:1529:1: error: size of unnamed array is negative >> request.h:1530:1: error: size of unnamed array is negative >> request.h:1531:1: error: size of unnamed array is negative >> >> Each error represents the C_ASSERT code listed above. >> >> I'm probably missing something obvious here. Can someone please offer any >> advice on resolving these errors? > >>> we'd need more info like the actual struct get_desktop_workarea_request > > Hallo André, I missed your response to the list. > > This is what I have done. Wine compiles perfectly if I uncomment the > C_ASSERT lines. I note that Charles Davis said in another response that > request.h should not be modified. > > *** server/protocol.def *** > /* Retrieve the desktop workarea */ > @REQ(get_desktop_workarea) >RECT spi_workarea; /* values from SystemParametersInfo */ That should be a rectangle_t. The server doesn't actually use native Windows types. Chip
Re: request.h: size of unnamed array is negative
On Apr 13, 2013, at 7:39 AM, Hugh McMaster wrote: > I've been adding a new handler to Wine's server. Unfortunately, I've run > into a problem with C_ASSERT that I can't seem to resolve. > > In server/request.h, I've added the following code: STOP! You should modify server/protocol.def instead. The file you changed is automatically generated from protocol.def, along with a bunch of other files needed to make the server interface magic work. Chip
Re: Dosbox integration
On Apr 8, 2013, at 1:27 PM, Fabian Ebner wrote: > Hello, > I'm Fabian Ebner and work with wine as a hobby. > > I found that GetShortNameA converts the example path > C:\123456789\dn\DN.COM > to > C:\1234~Q4C\dn\DN.COM > which causes problems with dosbox integration. > Dosbox would need the path as > C:\123456~1\dn\DN.COM > Is there another function that converts the path in the way, dosbox > needs it, should it be implemented or should dosbox be able to handle > the first form of the path too? DOSBox already handles Wine-style short paths (DOSBox r3743). > > Also wine often tries to mount his z: drive, which isn't possible, > because dosbox already mounts an own Z: drive > http://www.dosbox.com/wiki/ZDrive > Maybe wine should mount his Z: as Y:? You can pass the -z switch to DOSBox's mount command to remap DOSBox's drive Z: to something else (DOSBox r3736). Chip
Re: Build and override a simple winelib DLL
On Apr 5, 2013, at 10:34 AM, Maxime Sednaoui wrote:
> Hi,
>
> First, I already asked for the same thing at the forum where I've been told
> to post here for my question
> Link here : http://forum.winehq.org/viewtopic.php?f=8&t=18675
>
> I have a Windows executable that load a really simple DLL (it is a test) and
> I want to create a Winelib DLL that will override the Windows DLL. Basically,
> I created mylib_main.c and mylib.spec to build the Winelib DLL with the
> command:
> winegcc -mwindows -o mylib.dll.so mylib_main.c -I${WINE_ROOT}/include -shared
> mylib.spec
> winebuild -w --def -o libmylib.def --export mylib.spec
>
> Now I have mylib.dll.so and I want to override mylib.dll
> What should I do ? I removed the Windows library but then I got a Page Fault
> when the function is called. I also tried to configure the override with
> winecfg or set environment variables like WINEDLLPATH or add a DllMain in my
> library. I don't understand how to proceed.
>
> Is this because of the way I build my library ? Or maybe I forget a step to
> link it properly ?
Actually, it's much simpler than that.
Your Winelib DLL doesn't export a function called myfunc(), but the native DLL
does. (Try running:
$ winedump -jexport mylib.dll
to see what I mean.)
Your test app LoadLibrary()'s mylib.dll, then GetProcAddress()'s myfunc() from
it. (I know this because it doesn't directly call myfunc(). Run:
$ winedump -jimport myapp.exe
to verify this.) When it does this with your Winelib DLL, GetProcAddress()
returns NULL and your program crashes--probably because it doesn't check for
NULL before calling the function. (Of course, the whole point of
GetProcAddress() is to be able to check if a function exists in a DLL before
calling it. If you don't check for NULL, then why bother with it in the first
place? But I digress.)
Chip
Re: Mac driver status: ready for contributions
I have one more of my own to add: * Fix crash whenever an app makes a GLU call. I suspect this is because Mesa's GLU calls Mesa's libGL--which crashes horribly because there's no Mesa/GLX context current. I see two ways to fix that. One is to make GLU dispatch go through the driver. The other is to actually implement glu32 (i.e. not as a forwarder to the system GLU). I'm not sure how AJ will feel about the first one--and I probably won't know until next week. The second one... writing a GLU is a lot of work. We could use SGI's (as Mesa does), but SGI GLU is largely written in C++--and I *know* AJ won't like that. There's probably something I'm missing here, though. I'd be happy to have that pointed out to me. Chip
Re: [PATCH 4/5] winemac: Implement rudimentary support for system tray icons as Mac status items.
On Mar 18, 2013, at 2:23 PM, Ken Thomases wrote: > On Mar 18, 2013, at 2:15 PM, Ken Thomases wrote: > >> On Mar 18, 2013, at 3:03 PM, C.W. Betts wrote: >> >>> On Mar 17, 2013, at 9:40 PM, Ken Thomases wrote: >>> Doesn't support right-clicks, mouse moves, or notification balloons. >>> Notification balloons can probably be done using either Notification Center >>> or Growl >> >> >> Yeah, I was thinking that the notification center is the right way to go. > > Josh reminds me that only code-signed apps can use the Notification Center, > so that may not be very useful. *sigh* So what? It's actually possible to self-sign executables. (If you don't have a real code-signing certificate, you have to do this to build and use GDB or LLDB from source on Mac OS.) You probably won't be able to distribute the resulting executable, though. LLDB has a nice document describing how you'd go about creating a self-signed certificate. You can find it here: http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/code-signing.txt Though I wonder if it's a good idea to ask users to create a self-signed certificate just so Wine can use the Notification Center... >> I'm not sure if we want to use Growl given that it's not part of the OS, but >> I guess I don't feel very strongly one way or another. Most apps that want Growl come with their own Growl framework. Obviously, we can't do that for vanilla Wine. What we really need for this is some way to dynamically load and use frameworks (according to the standard rules for finding frameworks). That way, we can check for Growl at runtime and use it if it's present. I have a small library that wraps the CFBundle API in a dlopen(3)-style API. (As a matter of fact, I wrote it specifically to see if we could do something like that for Wine. As I recall, it was around the time we got OpenAL support.) Or, we could just check for it in configure (like C.W. said), if that's easier. I guess it really depends on AJ, and we won't be hearing from him for a while. At this point, though, I'm wondering if it wouldn't just be easier to have Explorer draw the balloons itself à la Windows XP. Chip
Re: [1/3] Make mac driver the default on OS X
On Mar 7, 2013, at 1:23 PM, Ken Thomases wrote: > On Mar 7, 2013, at 12:03 PM, Charles Davis wrote: > >> On Mar 6, 2013, at 7:56 AM, Ken Thomases wrote: >> >>> On Mar 6, 2013, at 8:24 AM, >>> wrote: >>> >>>> Bug report: >>>> Toying around with built-in notepad, clock, winhlp32, I noticed that >>>> notepad and winhlp32 are not resizable, whereas the system >>>> preferences "control" is. By comparison, with the x11 driver, >>>> notepad's window is resizable even though it has no triangle >>>> widget at the bottom left. >>> >>> Works here™. I can resize notepad and winhlp32 just fine. >> The problem is that the ability to resize windows by dragging their borders >> with the mouse was added in Lion. I'll bet Jörg is running Snow Leopard, >> where you can only resize windows by dragging the size box in the lower >> right (for me, anyway) corner. > > I'm running Snow Leopard, myself. > >> Except that many windows don't even have size boxes, even though you can >> still resize them by clicking and dragging their lower-right corner. >> >> If a window doesn't have a size box already (usually, a status bar with the >> SBARS_SIZEGRIP style), we should add a transparent one ourselves on SL, >> similar to what Xplugin does. Or, we should change the cursor into >> IDC_SIZENWSE when the pointer hovers over the corner. > > Alexandre specifically suggested that I suppress the grow box in the Mac > driver since drawing resize widgets should be up to the Windows app, so > that's what I did. It's the call to [window setShowsResizeIndicator:NO] in > cocoa_window.m. > > Also, Jörg already was aware that windows may be resized when they don't show > grow box, since he noted that there isn't one with the X11 driver. So what > he reported is something else. I thought he was referring to the Windows size grip--the one that you get when you put a status bar Common Control at the bottom of your window and give it the SBARS_SIZEGRIP style. There is a white grow box for me in the lower-right corner when I use the X11 driver. He must have been using a different WM than the default quartz-wm. If my diagnosis was inaccurate, then I wonder why he really couldn't resize the windows by dragging the corner... I don't have trouble resizing the windows, either. In the case that the window doesn't have its own grow box, though, it can be hard to tell that you actually still can resize the window by dragging the corner. (In notepad's case, it's weird, because I can click and drag the Down button on the scroll bar to resize the window. It happens to be about where the native grow box would have been drawn if it weren't turned off.) On Windows, resizable windows have at least a thicker frame (THICKFRAME style), and they usually also have the CLIENTEDGE and WINDOWEDGE extended styles (giving the appearance of a frame that you can grab and drag to resize the window). The Quartz window server precludes that with its pixel-thin border and insistence that you grab the lower-right corner--at least, prior to Lion. That's why I suggested changing the cursor to SIZENWSE at the lower-right corner. I should really write a patch that does that :). > > >>>> Also, the virtual desktop seems gone or not yet implemented. This is a key >>>> requirement for enough apps that do not handle today's huge resolutions. >>> >>> There is no mechanism for one Mac process to draw into the windows of >>> another. >> But there is--an indirect one, anyway. You can have everyone else draw into >> an IOSurface, and then share the IOSurface with Explorer (which I assume is >> responsible for managing the desktop window). You can even use an IOSurface >> as a GL texture (and, by extension, render with OpenGL into the IOSurface). >> This is how Chrome (and probably Safari too, since it uses the same >> underlying engine) implements sandbox'd rendering: the renderer draws the >> page into an IOSurface, then the browser draws the IOSurface into the >> window. And yes, this will work on Snow Leopard. > > I'm aware of IOSurface. It's one of the shared-memory mechanisms I mentioned > as being in consideration. As always, patches welcome! ;) Guess I'll get right to work on that ;). > > >>>> Another annoyance was that there's no HIDE function or short cut and some >>>> dialogues do not provide the orange button (middle one) to iconify the >>>> window. >>>> As a result, those pesky windows clutter your sc
Re: [1/3] Make mac driver the default on OS X
On Mar 6, 2013, at 7:56 AM, Ken Thomases wrote: > On Mar 6, 2013, at 8:24 AM, > wrote: > >> Bug report: >> Toying around with built-in notepad, clock, winhlp32, I noticed that >> notepad and winhlp32 are not resizable, whereas the system >> preferences "control" is. By comparison, with the x11 driver, >> notepad's window is resizable even though it has no triangle >> widget at the bottom left. > > Works here™. I can resize notepad and winhlp32 just fine. The problem is that the ability to resize windows by dragging their borders with the mouse was added in Lion. I'll bet Jörg is running Snow Leopard, where you can only resize windows by dragging the size box in the lower right (for me, anyway) corner. Except that many windows don't even have size boxes, even though you can still resize them by clicking and dragging their lower-right corner. If a window doesn't have a size box already (usually, a status bar with the SBARS_SIZEGRIP style), we should add a transparent one ourselves on SL, similar to what Xplugin does. Or, we should change the cursor into IDC_SIZENWSE when the pointer hovers over the corner. > > >> Also, the virtual desktop seems gone or not yet implemented. This is a key >> requirement for enough apps that do not handle today's huge resolutions. > > There is no mechanism for one Mac process to draw into the windows of another. But there is--an indirect one, anyway. You can have everyone else draw into an IOSurface, and then share the IOSurface with Explorer (which I assume is responsible for managing the desktop window). You can even use an IOSurface as a GL texture (and, by extension, render with OpenGL into the IOSurface). This is how Chrome (and probably Safari too, since it uses the same underlying engine) implements sandbox'd rendering: the renderer draws the page into an IOSurface, then the browser draws the IOSurface into the window. And yes, this will work on Snow Leopard. > > I'm not sure it's worth it. In my experience, the virtual desktop has more > often been used to work around X window manager limitations. The hope is > that we have greater control with the Mac driver. If all else fails, the X11 > driver is still available. True. Anyone who'd even bother to set up a virtual desktop would probably be willing to go to the trouble of installing XQuartz anyway. > > >> Another annoyance was that there's no HIDE function or short cut and some >> dialogues do not provide the orange button (middle one) to iconify the >> window. >> As a result, those pesky windows clutter your screen. >> That alone is enough reason to me a reason not to use that driver. It is not >> acceptable that one cannot get rid of a set of windows! >> Example: wine control, then navigate to the root CA certificates. > > More items can be added to the menus easily enough. However, I'm loathe to > assign the usual keyboard shortcuts. The problem is that the Command key is > used to generate Alt keystrokes and it's relatively likely that a Windows > program will want to receive Alt-H for its menus. Why aren't we using Option as Alt? Nearly every Mac keyboard labels it as "Alt" these days. Is typing characters like 'ü' and 'ø' and '∆' really that important? :) Chip
Re: [PATCH] winebuild: Use $CCAS to assemble if found
On Feb 3, 2013, at 9:36 PM, Alexandre Rostovtsev wrote:
> On Sun, 2013-02-03 at 20:27 -0700, Charles Davis wrote:
>> If the user doesn't set CCAS--which she doesn't the majority of the
>> time--configure will pick up the first of {clang, gas, as} in the PATH. Are
>> you sure that's what you want?
>
> I had attempted to preserve the behavior that exists in wine-1.5.23 by
> default because I assumed there was some good reason for it (even though
> I could not see it). But if you agree that behavior was undesirable,
> then of course it would be better to change the order depending on the
> platform, and check for {clang, gas, as} on OSX, and {gas, as, clang} on
> other platforms.
I considered doing that, but I figured it would make the code more complicated.
>
>> Perhaps we should just not define CCAS if the user didn't specify it. Then
>> below, you can wrap the block you added in an #ifdef.
>
> My patch skips the CCAS block if strlen( CCAS ) == 0, which is basically
> equivalent to what you propose.
I don't think you understand exactly what AC_CHECK_TOOLS() does. If one of
{clang, gas, as} exists in the path at *configure* time (prefixed with a CHOST
triple or otherwise), strlen( CCAS ) *won't* be 0, because AC_CHECK_TOOLS()
will pick one up. In fact, it will *never* be zero in this instance, because
even if it doesn't find one of them, it'll just use the C compiler like you
told it to.
And so I ask you again, are you sure you actually want to do this? Because I
think you really don't. Otherwise, I wouldn't be asking :).
I'm sorry if I wasn't perfectly clear before.
>
>> You may recall that one of the earlier versions (later than the one that
>> detected Clang in configure) used strstr(3) to detect Clang; I was then told
>> not to use it. I suspect this is because some systems' strstr(3) exhibits
>> quadratic-time behavior. I don't know if you can avoid that in this case,
>> though. Maybe you can just grab the basename and strip off the CTARGET
>> prefix; then you should just be able to do a strcmp(3). Or am I missing
>> something?
>
> Even if strstr(x,y) is quadratic in strlen(x) and strlen(y), here it is
> being called on two *constant* strings: CCAS and "clang". So the runtime
> penalty is in fact constant :)
Only if the compiler knows how to optimize strstr(3) :).
>
> But it's probably better to avoid this penalty altogether. For example,
> by checking in configure whether CCAS is Clang or GAS, and defining an
> appropriate flag.
Go for it. Can't speak for AJ though; he has the final word on anything that
goes in.
Chip
>
> -Alexandre.
>
Re: Compiling Wine on Mac OS X 10.8.2?
On Feb 4, 2013, at 10:27 AM, Jeremiah Flerchinger wrote: > Apple's GCC 4.2.1 version 5666.3 > > > > commdlg.vqed9R.s:259:2: error: invalid operand for instruction > lrecompobj.IYZvhS.st:w > 1037 : 2 : error: invalid operand for instruction > ^ > lretw > ^ > compobj.IYZvhS.s:1150:2: error: invalid operand for instruction > lretw > ^ > compobj.IYZvhS.s:1195:2: error: invalid operand for instruction > lretw > ^ > compobj.IYZvhS.s:1204:2: error: invalid operand for instruction > lretw > ^ > compobj.IYZvhS.s:1213:2: error: invalid operand for instruction > lretw > ^ > compobj.IYZvhS.s:1222:2: error: invalid operand for instruction > lretw > ^ > compobj.IYZvhS.s:1231:2: error: invalid operand for instruction > lretw > ^ > winebuild: /usr/bin/clang failed with status 1 > winegcc: ../../tools/winebuild/ > winebuild failed > make[1]: *** [commdlg.dll16.so] Error 2 > make: *** [dlls/commdlg.dll16] Error 2 > make: *** Waiting for unfinished jobs > ../../../tools/winegcc/winegcc -m32 -B../../../tools/winebuild > --sysroot=../../.. -s -Wb,-F,credui_test.exe credui.o testlist.o -o > credui_test-stripped.exe.so ../../../libs/port/libwine_port.a -lcredui > -L/Users/jeremiah/wine/wine-git/lib -L/opt/X11/lib -framework CoreServices > -lz -L/opt/X11/lib -lGL -lGLU > winebuild: /usr/bin/clang failed with status 1 > winegcc: ../../tools/winebuild/winebuild failed > make[1]: *** [compobj.dll16.so] Error 2 > make: *** [dlls/compobj.dll16] Error 2 > echo "credui_test.exe TESTRES \"credui_test-stripped.exe.so\"" | > ../../../tools/wrc/wrc --nostdinc --po-dir=../../../po -m32 -I. -I. > -I../../../include -I../../../include -DWINE_STRICT_PROTOTYPES > -DWINE_NO_NAMELESS_EXTENSION -DWIDL_C_INLINE_WRAPPERS -o > ../../../programs/winetest/credui_test.res > could not run 'make -j3' in /Users/jeremiah/wine/build/wine-git - exiting Yep, this is related to my patch alright. I'm willing to bet you're still running Xcode 4.5, too. Try upgrading to 4.6. Chip > > > On Sun, Feb 3, 2013 at 11:02 PM, Bill Broach > wrote: > Which version of gcc are you compiling it with? > > Im able to compile no issue with: i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 > (Apple Inc. build 5666) (dot 3) > > On Feb 3, 2013, at 3:58 PM, Charles Davis wrote: > > > > > On Feb 3, 2013, at 10:50 AM, Saulius Krasuckas wrote: > > > >> * On Sun, 3 Feb 2013, Jeremiah Flerchinger wrote: > >> > >>> Is anyone compiling Wine from the git repository for OS X version > >>> 10.8.2? > >> > >> Not me... > >> > >>> At first I thought I broke my toolchain and could no longer compile Wine > >>> at all, but this is not the case. I can still compile old releases, but > >>> can no longer compile from git. > >> > >> ... but I would try running a regression test (git bisect) in your case. > > Why do I get the feeling that when you do, you'll end up at commit c14bdaf? > > > > How exactly does it break? > > > > Chip > > > >> > >> S. > >> > >> > > > > > > > >
Re: [PATCH] winebuild: Use $CCAS to assemble if found
Hi,
On Feb 3, 2013, at 7:33 PM, Alexandre Rostovtsev wrote:
> Commit c14bdaf1 made winebuild use Clang to assemble if found.
>
> However, just because a user has some version of Clang installed, it
> does not mean that she wants to use Clang to assemble Wine. For example,
> a user who has both Clang and GAS installed may want to use GAS to avoid
> textrels (see https://bugs.gentoo.org/show_bug.cgi?id=455308).
Long term, that should really get fixed in LLVM/Clang. I'll file a PR (if one
wasn't already).
>
> This patch allows the user to override which assembler gets used by
> exporting CCAS at Wine configure time; the name CCAS was chosen for
> compatibility with automake's standard AM_PROG_AS macro.
I wrote the patch that prompted this one. And I'll freely admit, this is why I
wanted to limit that patch to Mac OS--to minimize fallout on other platforms
(like, obviously, Gentoo :).
> ---
> configure | 106
> configure.ac| 4 ++
> tools/winebuild/Makefile.in | 5 ++-
> tools/winebuild/utils.c | 12 +
> 4 files changed, 126 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index e3253ee..d0b 100755
> --- a/configure
> +++ b/configure
> @@ -732,6 +732,8 @@ FLEX
> TOOLSDIR
> WOW64_DISABLE
> TARGETFLAGS
> +ac_ct_CCAS
> +CCAS
> CPPBIN
> ac_ct_CXX
> CXXFLAGS
> @@ -861,6 +863,7 @@ CPPFLAGS
> CXX
> CXXFLAGS
> CCC
> +CCAS
> CPP
> XMKMF'
>
> @@ -1549,6 +1552,7 @@ Some influential environment variables:
> you have headers in a nonstandard directory
> CXX C++ compiler command
> CXXFLAGSC++ compiler flags
> + CCASAssembler command
> CPP C preprocessor
> XMKMF Path to xmkmf, Makefile generator for X Window System
>
> @@ -4075,6 +4079,108 @@ cat >>confdefs.h <<_ACEOF
> _ACEOF
>
>
> +
> +if test -n "$ac_tool_prefix"; then
> + for ac_prog in clang gas as
> + do
> +# Extract the first word of "$ac_tool_prefix$ac_prog", so it can be a
> program name with args.
> +set dummy $ac_tool_prefix$ac_prog; ac_word=$2
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
> +$as_echo_n "checking for $ac_word... " >&6; }
> +if ${ac_cv_prog_CCAS+:} false; then :
> + $as_echo_n "(cached) " >&6
> +else
> + if test -n "$CCAS"; then
> + ac_cv_prog_CCAS="$CCAS" # Let the user override the test.
> +else
> +as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
> +for as_dir in $PATH
> +do
> + IFS=$as_save_IFS
> + test -z "$as_dir" && as_dir=.
> +for ac_exec_ext in '' $ac_executable_extensions; do
> + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
> +ac_cv_prog_CCAS="$ac_tool_prefix$ac_prog"
> +$as_echo "$as_me:${as_lineno-$LINENO}: found
> $as_dir/$ac_word$ac_exec_ext" >&5
> +break 2
> + fi
> +done
> + done
> +IFS=$as_save_IFS
> +
> +fi
> +fi
> +CCAS=$ac_cv_prog_CCAS
> +if test -n "$CCAS"; then
> + { $as_echo "$as_me:${as_lineno-$LINENO}: result: $CCAS" >&5
> +$as_echo "$CCAS" >&6; }
> +else
> + { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
> +$as_echo "no" >&6; }
> +fi
> +
> +
> +test -n "$CCAS" && break
> + done
> +fi
> +if test -z "$CCAS"; then
> + ac_ct_CCAS=$CCAS
> + for ac_prog in clang gas as
> +do
> + # Extract the first word of "$ac_prog", so it can be a program name with
> args.
> +set dummy $ac_prog; ac_word=$2
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
> +$as_echo_n "checking for $ac_word... " >&6; }
> +if ${ac_cv_prog_ac_ct_CCAS+:} false; then :
> + $as_echo_n "(cached) " >&6
> +else
> + if test -n "$ac_ct_CCAS"; then
> + ac_cv_prog_ac_ct_CCAS="$ac_ct_CCAS" # Let the user override the test.
> +else
> +as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
> +for as_dir in $PATH
> +do
> + IFS=$as_save_IFS
> + test -z "$as_dir" && as_dir=.
> +for ac_exec_ext in '' $ac_executable_extensions; do
> + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
> +ac_cv_prog_ac_ct_CCAS="$ac_prog"
> +$as_echo "$as_me:${as_lineno-$LINENO}: found
> $as_dir/$ac_word$ac_exec_ext" >&5
> +break 2
> + fi
> +done
> + done
> +IFS=$as_save_IFS
> +
> +fi
> +fi
> +ac_ct_CCAS=$ac_cv_prog_ac_ct_CCAS
> +if test -n "$ac_ct_CCAS"; then
> + { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_CCAS" >&5
> +$as_echo "$ac_ct_CCAS" >&6; }
> +else
> + { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
> +$as_echo "no" >&6; }
> +fi
> +
> +
> + test -n "$ac_ct_CCAS" && break
> +done
> +
> + if test "x$ac_ct_CCAS" = x; then
> +CCAS=""$CC""
> + else
> +case $cross_compiling:$ac_tool_warned in
> +yes:)
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not
> prefixed with host triplet" >&5
> +$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet"
> >&2;}
> +ac_tool_warned=yes ;;
> +esac
> +CCAS=$ac_ct_CCAS
> + fi
> +fi
> +
> +
> case $host in
> *-darwin*)
> if test "x$enable_win64" = "xyes"
> diff --git a/configure
Re: Compiling Wine on Mac OS X 10.8.2?
On Feb 3, 2013, at 10:50 AM, Saulius Krasuckas wrote: > * On Sun, 3 Feb 2013, Jeremiah Flerchinger wrote: > >> Is anyone compiling Wine from the git repository for OS X version >> 10.8.2? > > Not me... > >> At first I thought I broke my toolchain and could no longer compile Wine >> at all, but this is not the case. I can still compile old releases, but >> can no longer compile from git. > > ... but I would try running a regression test (git bisect) in your case. Why do I get the feeling that when you do, you'll end up at commit c14bdaf? How exactly does it break? Chip > > S. > >
Re: Clang warnings on OS X ML
On Jan 30, 2013, at 6:44 PM, C.W. Betts wrote: > When compiling Wine using Clang, there are a bunch of warnings that pop up, > such as: > ld: warning: could not create compact unwind for .L__wine_spec_call16_p_pw: > dwarf uses DW_CFA_same_value > ld: warning: could not create compact unwind for ___wine_stub_VARBSTRFROMR8: > stack subq instruction is too different from dwarf stack size > > On win16 DLLs. > > And these warnings are with general DLL: > ld: warning: could not create compact unwind for ___wine_stub__aullshr: stack > subq instruction is too different from dwarf stack size > ld: warning: could not create compact unwind for > .L__wine_spec_relay_entry_point_52: stack subq instruction is too different > from dwarf stack size These are all related to compact unwind support--slated for inclusion in DWARF 5. Don't worry: they're harmless. The linker will just create normal unwind info instead... I think. They also all happen in winebuild-generated code--normal C code is (largely) unaffected. I'm not sure if we want to fix this or not: we don't use DWARF unwind info at all in 32-bit code, and even if we did, we certainly don't know how to parse the compact unwind data. 64-bit code is another matter, but we're a long way from supporting Wine64 on Mac--mostly due to the fact that Wine wants to use the GS segment for itself, but Mac OS is already using it. (tl;dr: Don't worry about it for now, even if all that went over your head. :) > > > Another worrying warning is that __force_align_arg_pointer__ being an unknown > attribute. Now that's not right. I specifically implemented this attribute in Clang myself just so I could build Wine with it. There were some *errors* about this attribute being used in a function pointer type, but as of Monday on Clang trunk, they're just warnings--really annoying warnings that I'm sure AJ won't want to have to turn off. (I know. I tried.) I also recall once that Clang didn't always accept the __-bracketed versions of some GNU attributes, which should also be fixed (and has been for several LLVM releases now!). I'd be surprised if Apple clang doesn't have this latter fix yet, though Xcode 4.5 still had some pre-LLVM 3.1 version of Clang. Seriously, if you're not running the latest Xcode--which as of yesterday is 4.6--you should be. Apple often branches their own releases from LLVM/Clang trunk. (I always use Clang trunk directly myself, but that's partly because I'm also a part-time Clang developer.) > > There's also a lot of enum conversion warnings. They're harmless. Most of them are in Direct3D code, because the client DLLs and the WineD3D backend DLL use different (but compatible) enumeration types. A few are in tests that try to pass nonsense values like 0xdeadbeef that are outside the range of known enumerators. It's just Clang being pedantic about the enum rules in C. Don't know if AJ or Henri are willing to take patches to silence these warnings. > > There was also a linker warning about register usage, but I can't seem to > find it again. I'll bet it's another compact unwind-related warning. I recall seeing something to that effect myself--something along the lines of: ld: warning: could not create compact unwind for : %ebp not used for stack frame or something. Chip
Re: User driver function conventions
On Jan 19, 2013, at 1:09 PM, C.W. Betts wrote: > I'm wondering what the user driver functions GetScreenSaveActive and > SetScreenSaveActive are supposed to do. I have an implementation against > CodeWeaver's changes to Wine and I just want to make sure that I'm making the > functions properly. How should we know? (Well, those of us who don't work at CW anyway.) USER drivers don't even have those in (unmodified) Wine. I'm sorry if I come across as rude, but this mailing list is for plain Wine. If you have a question about CrossOver Wine, you should ask CodeWeavers. I'm sure that somewhere on their website, they have an email or a mailing list you can contact them with. Chip
Re: Ken Thomases : libwine: Use rpath-based install name and library references for libwine on Mac.
On Jan 11, 2013, at 12:46 PM, Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: f377591e98c490ca00e6479627832e41b2ad01b9 > URL: > http://source.winehq.org/git/wine.git/?a=commit;h=f377591e98c490ca00e6479627832e41b2ad01b9 > > Author: Ken Thomases > Date: Fri Jan 11 03:25:07 2013 -0600 > > libwine: Use rpath-based install name and library references for libwine on > Mac. Huh? I thought this broke running installed Wine for you. Why did you commit this anyway? (Or is there another email message that I didn't see? Gmail has been acting wonky lately about delivering my email...) Chip
Re: [PATCH 3/6] loader: On Mac, embed Info.plist in (__TEXT, __info_plist) section.
On Jan 7, 2013, at 9:15 AM, Ken Thomases wrote: > On Jan 7, 2013, at 1:23 AM, Per Johansson wrote: > >> On Mon, Jan 7, 2013 at 4:48 AM, Charles Davis wrote: >>> >>> With this, you won't be able to launch Wine from the Finder or with open(1) >>> prior to 10.6. >> >> I don't see how you'd do use open or the Finder to launch wine, could >> you explain more detailed? > > Yeah, I'm not sure it's a real problem, It won't be--I don't imagine anyone would want to double-click on the Wine executable, and they certainly wouldn't use open(1) when they could just run wine(1) directly--unless Wine grows support for file associations on the Mac. Then, when some poor user stuck on Leopard double-clicks on a file, expecting it to open up with Wine, it'll fail, because Wine declared to LaunchServices that it can't run on Leopard. I might be mistaken, since we'd probably end up just emitting app bundles with shell scripts that exec wine(1) directly, where LS wouldn't be involved in launching Wine itself. One area that might still be a problem, though, is if we associate *.exe files with Wine itself: then when a user double-clicks on a Win32 executable, LS will go straight to executing Wine. Don't know if that's possible with embedded Info.plist files, though. Chip > but that key should probably not be there anyway. I'll resubmit with that > removed. > > Thanks for reviewing. > > Cheers, > Ken >
Re: [PATCH 3/6] loader: On Mac, embed Info.plist in (__TEXT, __info_plist) section.
On Jan 6, 2013, at 6:54 PM, Ken Thomases wrote: > diff --git a/loader/wine_info.plist.in b/loader/wine_info.plist.in > new file mode 100644 > index 000..c332649 > --- /dev/null > +++ b/loader/wine_info.plist.in > @@ -0,0 +1,28 @@ > + > + "http://www.apple.com/DTDs/PropertyList-1.0.dtd";> > + > + > +CFBundleDevelopmentRegion > +English > +CFBundleExecutable > +wine > +CFBundleIdentifier > +org.winehq.wine > +CFBundleInfoDictionaryVersion > +6.0 > +CFBundleName > +Wine > +CFBundlePackageType > +APPL > +CFBundleShortVersionString > +@PACKAGE_VERSION@ > +CFBundleSignature > + > +CFBundleVersion > +@PACKAGE_VERSION@ > +LSMinimumSystemVersion > +10.6 With this, you won't be able to launch Wine from the Finder or with open(1) prior to 10.6. Chip > +NSPrincipalClass > +WineApplication > + > + >
Re: [PATCH] winebuild: Use Clang to assemble if its integrated assembler is being used.
On Jan 2, 2013, at 11:23 AM, Per Johansson wrote: > On Wed, Jan 2, 2013 at 5:05 PM, André Hentschel wrote: >> >> Not sure if you can do it like that, as i understand it winebuild should >> always be able to crosscompile something, these ifdefs would destroy that >> feature. Only on Mac OS :). > > I suppose the correct way is to always use clang without target_alias > prefix, But Clang actually supports target triple prefixes. I'll just avoid passing $CC to winebuild and make it invoke Clang directly instead. Chip
Re: winebuild: Add configure option to use llvm-mc as assembler.
On Jan 2, 2013, at 5:35 AM, Per Johansson wrote: > On Wed, Jan 2, 2013 at 3:12 AM, Charles Davis wrote: > >> What kind of undefined symbol errors? Other than the ones I got because >> as(1) from cctools can't grok CFI pseudo-ops (and probably never will >> because of Clang), I don't know of any symbol problems building Wine with >> Clang on Mac OS. Might have something to do with my system version (I'm >> still on 10.6, and I probably won't move until I find some way to run -arch >> ppc apps since Apple gutted Rosetta from 10.7...) > > I think I simply forgot to add the -c flag, silly me. Patch seems to > work, I'm getting some compile errors but I suppose it's a different > problem: > > avifile.DPJO1m.s:443:2: error: invalid operand for instruction >lretw >^ > avifile.DPJO1m.s:580:2: error: invalid operand for instruction >lretw >^ That's fixed in LLVM/Clang trunk. (I know, because I fixed it myself. A while ago, actually; I'm surprised Xcode doesn't have it yet.) Maybe the next version of Xcode will pick up the fix. Someone should really prod Apple about this :). > >> Do you actually not have the Wine vs. Mach cpu_type_t issue with Clang? I'd >> find that interesting. > > Yes, it doesn't appear with clang, and also not with gcc-mp-4.x from > macports. I suspect that's because Clang and newer GCC are smarter about identical typedefs. The ObjC BOOL vs. Wine BOOL issue wasn't about identical typedefs, because an ObjC BOOL is a "signed char" while a Wine BOOL is an "int". But a Mach cpu_type_t is an "integer_t"... which, ultimately, is a plain "int", the same as Wine's cpu_type_t. > I could open a radar myself (only have free membership), but > I don't mind it too much since the default gcc compiler doesn't work > anyway (wine bug 28030), so it might just as well get an error > compiling if we get clang working. Yeah, I'm not sure anyone really cares about the dead Apple GCC branch anymore... except AJ, but that's because his old Mac mini is stuck on 10.5, where we don't even have that problem. So long as Wine compiles with Apple GCC 4.x on Leopard, he'll be happy :). Chip > > Regards, > -- > Per Johansson
Re: winebuild: Add configure option to use llvm-mc as assembler.
On Jan 1, 2013, at 4:36 PM, Per Johansson wrote: > On Tue, Jan 1, 2013 at 7:11 PM, Per Johansson wrote: >> On Tue, Jan 1, 2013 at 6:00 PM, Charles Davis wrote: >>> >>> The right thing IMO is to test if we're compiling with Clang. If we are, >>> then we should test if Clang is using its integrated assembler; if it is, >>> then we should invoke Clang instead of the system assembler to assemble. >>> This way, the user doesn't have to pass yet another option to configure in >>> case he's using Clang. >>> >>> I have a patch to hack-fix winebuild to invoke Clang if we're being >>> compiled by Clang; I can fix it to test for Clang and Clang's integrated >>> assembler in configure and send it to the list--something I really >>> should've done a while ago. >> >> Sure, sounds like a better plan. Patch is sent. >> I tried briefly to use clang, but >> there were a lot of undefined symbol errors I wasn't sure how to fix. What kind of undefined symbol errors? Other than the ones I got because as(1) from cctools can't grok CFI pseudo-ops (and probably never will because of Clang), I don't know of any symbol problems building Wine with Clang on Mac OS. Might have something to do with my system version (I'm still on 10.6, and I probably won't move until I find some way to run -arch ppc apps since Apple gutted Rosetta from 10.7...) >> Tell me if you want some help with the patch. >> > > Btw, I should probably add that there's currently no way to build > unpatched wine on 10.8 (and probably 10.7), as gcc-apple-4.2 get a > conflict about cpu_type_t That probably means some system header is including--directly or indirectly-- (the system header that defines Mach's cpu_type_t) somewhere inside the server (which defines Wine's cpu_type_t), where it wasn't before. Want me to file a radar? (The last time something like this happened, I was told to file a radar with Apple. Amazingly, it worked! It probably helped that I pointed out which header pulled in a header that it didn't need; this time might be more difficult.) > and pure gcc is not up to date with the > latest Objective-C syntax in the system headers. Being able to build > with clang would help a lot. Do you actually not have the Wine vs. Mach cpu_type_t issue with Clang? I'd find that interesting. Chip > > Regards, > -- > Per Johansson
Re: winebuild: Add configure option to use llvm-mc as assembler.
On Jan 1, 2013, at 9:35 AM, Per Johansson wrote:
> Needed to build with clang on OS X, the normal as program can't parse clang
> output.
> It's a configure option since llvm-mc takes different options than the normal
> assembler, and on OS X is most often installed by a different name
> (llvm-mc-mp-3.1 in my case).
But llvm-mc isn't a tool intended to be used by the end user. It's an LLVM
developer's tool intended to be used to test and play with LLVM's MC library
(which Clang uses to implement its integrated assembler). The help output even
says "llvm machine code playground". That's why Apple doesn't distribute it
with Xcode.
The right thing IMO is to test if we're compiling with Clang. If we are, then
we should test if Clang is using its integrated assembler; if it is, then we
should invoke Clang instead of the system assembler to assemble. This way, the
user doesn't have to pass yet another option to configure in case he's using
Clang.
I have a patch to hack-fix winebuild to invoke Clang if we're being compiled by
Clang; I can fix it to test for Clang and Clang's integrated assembler in
configure and send it to the list--something I really should've done a while
ago.
Chip
> ---
> configure.ac | 8
> tools/winebuild/build.h | 6 +-
> tools/winebuild/import.c | 4 ++--
> tools/winebuild/res32.c | 2 +-
> tools/winebuild/utils.c | 22 +-
> 5 files changed, 33 insertions(+), 9 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 620ad07..84232e0 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -59,6 +59,7 @@ AC_ARG_WITH(jpeg, AS_HELP_STRING([--without-jpeg],[do
> not use JPEG]),
> [if test "x$withval" = "xno"; then ac_cv_header_jpeglib_h=no; fi])
> AC_ARG_WITH(ldap, AS_HELP_STRING([--without-ldap],[do not use LDAP]),
> [if test "x$withval" = "xno"; then ac_cv_header_ldap_h=no;
> ac_cv_header_lber_h=no; fi])
> +AC_ARG_WITH(llvm-mc, AS_HELP_STRING([--with-llvm-mc=NAME],[Use llvm-mc as
> assembler]))
> AC_ARG_WITH(mpg123,AS_HELP_STRING([--without-mpg123],[do not use the
> mpg123 library]),
> [if test "x$withval" = "xno"; then ac_cv_header_mpg123_h=no; fi])
> AC_ARG_WITH(openal,AS_HELP_STRING([--without-openal],[do not use OpenAL]),
> @@ -294,6 +295,13 @@ AC_CHECK_PROGS(CONVERT, convert, false)
> AC_CHECK_PROGS(ICOTOOL, icotool, false)
> AC_CHECK_PROGS(MSGFMT, msgfmt, false)
>
> +dnl Check if user wants llvm-mc
> +if test "x${with_llvm_mc:-no}" != "xno"
> +then
> + if test "${with_llvm_mc}" = "yes"; then with_llvm_mc=llvm-mc; fi
> + AC_DEFINE_UNQUOTED(LLVM_MC, ["${with_llvm_mc}"], [Define to name of
> llvm-mc program, if preferred.])
> +fi
> +
> if test "x$enable_maintainer_mode" != "xyes"
> then
> AC_SUBST([MAINTAINER_MODE],[\#])
> diff --git a/tools/winebuild/build.h b/tools/winebuild/build.h
> index 05adf31..71e87f6 100644
> --- a/tools/winebuild/build.h
> +++ b/tools/winebuild/build.h
> @@ -209,6 +209,10 @@ struct strarray
> #define IMAGE_SUBSYSTEM_WINDOWS_CUI 3
> #define IMAGE_SUBSYSTEM_WINDOWS_CE_GUI 9
>
> +/* find_tool flags */
> +
> +#define FT_SKIP_TARGET_ALIAS 1
> +
> /* global functions */
>
> #ifndef __GNUC__
> @@ -246,7 +250,7 @@ extern int output( const char *format, ... )
> extern void output_cfi( const char *format, ... )
>__attribute__ ((__format__ (__printf__, 1, 2)));
> extern void spawn( struct strarray *array );
> -extern char *find_tool( const char *name, const char * const *names );
> +extern char *find_tool( const char *name, const char * const *names, int
> flags );
> extern struct strarray *get_as_command(void);
> extern struct strarray *get_ld_command(void);
> extern const char *get_nm_command(void);
> diff --git a/tools/winebuild/import.c b/tools/winebuild/import.c
> index c73b86c..821b5b8 100644
> --- a/tools/winebuild/import.c
> +++ b/tools/winebuild/import.c
> @@ -1325,14 +1325,14 @@ void output_import_lib( DLLSPEC *spec, char **argv )
> fclose( output_file );
> output_file = NULL;
>
> -strarray_add( args, find_tool( "dlltool", NULL ), "-k", "-l",
> output_file_name, "-d", def_file, NULL );
> +strarray_add( args, find_tool( "dlltool", NULL, 0 ), "-k", "-l",
> output_file_name, "-d", def_file, NULL );
> spawn( args );
> strarray_free( args );
>
> if (argv[0])
> {
> args = strarray_init();
> -strarray_add( args, find_tool( "ar", NULL ), "rs", output_file_name,
> NULL );
> +strarray_add( args, find_tool( "ar", NULL, 0 ), "rs",
> output_file_name, NULL );
> strarray_addv( args, argv );
> spawn( args );
> strarray_free( args );
> diff --git a/tools/winebuild/res32.c b/tools/winebuild/res32.c
> index 729aa2f..bddca83 100644
> --- a/tools/winebuild/res32.c
> +++ b/tools/winebuild/res32.c
> @@ -682,7 +682,7 @@ void output_res_o_file( DLLSPEC *spec )
> free( output_buffer );
>
> args = strarray_init();
> -strarray_add( args, f
Re: [PATCH] ntdll: Fix existing conftests for nanosecond precision time fields.
On Nov 29, 2012, at 2:22 PM, Charles Davis wrote:
>
> On Nov 29, 2012, at 11:47 AM, Alexandre Julliard wrote:
>
>> Charles Davis writes:
>>
>>> From: Charles Davis
>>>
>>> Autoconf checks for a field of a struct by using it in an if()
>>> expression. Of course, you can't do this for an aggregate field, so you
>>> must instead check a field of that aggregate instead. Up until now, the
>>> conftests for the st_?tim fields were all failing, even on systems that
>>> had them, because of this.
>>
>> It does a sizeof, which should work just fine.
> No it doesn't. This is the conftest.c template that it uses
> (ac_fn_c_check_member() function, at line 2036 in configure):
>
>
> /* end confdefs.h. */
> $5
> int
> main ()
> {
> static $2 ac_aggr;
> if (ac_aggr.$3)
> return 0;
> ;
> return 0;
> }
>
> I see no sizeof in there.
>
Oh wait... there's the second conftest later on in that function, that does use
sizeof. Sorry for the noise. (But I have to wonder why they don't just have one
test using sizeof... Autoconf is just one, big horrible hack.)
Chip
Re: [PATCH] ntdll: Fix existing conftests for nanosecond precision time fields.
On Nov 29, 2012, at 11:47 AM, Alexandre Julliard wrote:
> Charles Davis writes:
>
>> From: Charles Davis
>>
>> Autoconf checks for a field of a struct by using it in an if()
>> expression. Of course, you can't do this for an aggregate field, so you
>> must instead check a field of that aggregate instead. Up until now, the
>> conftests for the st_?tim fields were all failing, even on systems that
>> had them, because of this.
>
> It does a sizeof, which should work just fine.
No it doesn't. This is the conftest.c template that it uses
(ac_fn_c_check_member() function, at line 2036 in configure):
/* end confdefs.h. */
$5
int
main ()
{
static $2 ac_aggr;
if (ac_aggr.$3)
return 0;
;
return 0;
}
I see no sizeof in there.
Chip
Re: How to tell Mac from Linux wine within a Wine app? (steam hardware survey)
On Nov 10, 2012, at 12:03 PM, Scott Ritchie wrote: > Is there an easy way for the steam hardware survey to tell whether it's > running under Mac or Linux Wine? > > I remember discussing this issue with an engineer from Valve after asking > they make the % of Wine users public again. You can call the wine_get_host_version() function in ntdll. It's used by winetest to insert the host system info into its reports. Chip
Re: [spam-high] Re: [PATCH 3/7] advapi: Implement GetNamedSecurityInfoW on top of GetSecurityInfo (try 3).
On Nov 4, 2012, at 10:11 PM, Erich E. Hoover wrote: > If the object is resolvable with CreateFile then it doesn't matter if > it's a file, directory, named pipe, or some other miscellaneous thing. True, and of course by "file" I meant "any object that can act like a file," which includes directories, pipes, devices, etc. I will add that the 'type' parameter also affects how the path that gets passed in is parsed. But you're right, CreateFile() will fail anyway for those kinds of paths, so I guess it's OK to ignore the 'type' for now. > I templated part 2 after how GetSecurityInfo works (it also ignores > the SE_OBJECT_TYPE), I'm not even sure what type of object you'd call > the function with where it might matter. I can name at least four: registry keys (HKEY), services (SC_HANDLE), window stations (HWINSTA), and desktops (HDESK). On native, all those types of objects are protected with ACLs, and all those types have unique functions for manipulating them. But you don't have to worry about that for now; just supporting file-like objects is fine right now, especially since Wine only supports one user per prefix right now, so objects that exist in the file-system are the only ones where we have to worry about other users. (Besides, Wine probably doesn't even support multiple window station and desktop objects anyway...) Sorry for the noise. Chip > > Erich > > On Sun, Nov 4, 2012 at 3:15 PM, Charles Davis wrote: >> >> On Nov 4, 2012, at 1:30 AM, Erich E. Hoover wrote: >> >>> This patch implements GetNamedSecurityInfoW on top of the more >>> fundamental GetSecurityInfo function, permitting the return of more >>> accurate ownership information for files. PlayReady uses this >>> information to determine if its files have the appropriate >>> permissions, without the correct permissions it will attempt to recopy >>> the individualization file (and fail). Additionally, this patch adds >>> tests for retrieving the ACL information set on files. >>> >>> This version fixes some problems in the tests on older Windows >>> versions, sorry I didn't catch that earlier. It now also fixes a >>> mistake I made between testing try 2 and pushing it out :/ >> >>> +hfile = CreateFileW( name, access, >>> FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE, >>> + NULL, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, >>> 0 ); >> Only works on files right now, huh? You might then want to check to make >> sure the caller says it's a file by comparing the 'type' against >> SE_FILE_OBJECT, and return ERROR_CALL_NOT_IMPLEMENTED if they didn't. After >> all, part of the point of that parameter is to tell you which function you >> need to call to open the object in the first place :). (Same for patch 2.) >> >> Chip >>
Re: [PATCH 3/7] advapi: Implement GetNamedSecurityInfoW on top of GetSecurityInfo (try 3).
On Nov 4, 2012, at 1:30 AM, Erich E. Hoover wrote: > This patch implements GetNamedSecurityInfoW on top of the more > fundamental GetSecurityInfo function, permitting the return of more > accurate ownership information for files. PlayReady uses this > information to determine if its files have the appropriate > permissions, without the correct permissions it will attempt to recopy > the individualization file (and fail). Additionally, this patch adds > tests for retrieving the ACL information set on files. > > This version fixes some problems in the tests on older Windows > versions, sorry I didn't catch that earlier. It now also fixes a > mistake I made between testing try 2 and pushing it out :/ > +hfile = CreateFileW( name, access, > FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE, > + NULL, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, 0 > ); Only works on files right now, huh? You might then want to check to make sure the caller says it's a file by comparing the 'type' against SE_FILE_OBJECT, and return ERROR_CALL_NOT_IMPLEMENTED if they didn't. After all, part of the point of that parameter is to tell you which function you need to call to open the object in the first place :). (Same for patch 2.) Chip
Re: [PATCH] regedit: err() on printing
On Oct 12, 2012, at 6:12 AM, Dmitry Timoshkov wrote:
> Marcus Meissner wrote:
>
>> +ERR("printing is not yet implemented.\n");
>
> Printing a FIXME seems more appropriate.
Also, aren't programs supposed to use the prefixed calls (e.g. WINE_FIXME()
instead of FIXME())?
Chip
Re: [PATCH 1/4] jscript: Use custom string container instead of BSTR.
On Oct 11, 2012, at 4:16 AM, Jacek Caban wrote: > This patch alone makes SunSpider 0.9 17x faster. Seems to me that something is really wrong with our BSTR implementation if replacing it with a home-grown implementation speeds this up by a factor of 17. Chip
Re: CIA going down: KGB wants your commits!
On Sep 27, 2012, at 5:10 PM, Austin English wrote: > -- > -Austin > > -- Forwarded message -- > From: Martín Ferrari > Date: Thu, Sep 27, 2012 at 3:52 PM > Subject: CIA going down: KGB wants your commits! > To: debian-proj...@lists.debian.org, Debian Developers > > > > Hi there! > > Not to "to knock 'em when they're down", but since it seems that the CIA.vc > service has officially closed recently (cannot find exactly when did that > happen), I think it's worthwhile offering this little project we (dam@, > gregoa@, and me) have since a few years ago, called KGB (ha-ha). > > It's a very simple and dumb client-server architecture: IRC bots running in > our personal servers listen for SOAP messages sent by kgb-clients called > from post-commit hooks in repos out there. The bot just relays and formats > a message, nothing fancier than that. > > So, if you're looking for a simple IRC notification of your commits, this > might be of help. I'd like to put forward another alternative, from the guy who maintained the CIA scripts for git: http://www.catb.org/esr/irker/ (Yeah, that ESR.) After the CIA announcement, he rushed to get it out as a replacement, though he's seen this coming and has been working on this for quite some time. It's even backwards-compatible (to some extent) with CIA: it can take XML-RPC notifications sent by CIA clients. Just making sure you evaluate all your options. :) Oh, and personally, I wouldn't trust anything associated with the KGB. (Just kidding... ;) Chip > > You can either run your own bot (debian package kgb-bot), or use ours. As > for the client, alioth does not have it installed, but you can run it off > /home/groups/kgb. There's a sample configuration there too. In > /home/groups/pkg-perl/meta/pkg-perl-post-receive you can see how to use it > from a post-commit hook. > > If you rather use our bots, we'll need you to provide: a project/repository > name, an IRC channel, and a password (used to avoid spam, not really > secure). > > -- > Martín Ferrari > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: > http://lists.debian.org/cal60pd_7zopk4w4rta49-jymxzkou+k7ddqzuiqsp32kz9b...@mail.gmail.com > >
Re: [PATCH 3/3] hhctrl.ocx: Resize the window when HH_SET_WIN_TYPE is called (try 3, resend 2).
On Sep 2, 2012, at 11:23 AM, Erich E. Hoover wrote: > This patch adds the final feature to make the embedded help work > properly, allowing Elster to resize the HTML Help window whenever the > application window is resized. Without this feature the HTML Help > window would always remain at the same size as when the window was > first created. Er, uh, what patch? Chip
Re: How to convert msvcp names to legible names?
On Aug 18, 2012, at 6:04 PM, Bruno Jesus wrote: > Which is the roseta stone used to read all msvcp function names like > "msvcp80.dll.??0?$basic_stringstream@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@QAE@H@Z, > aborting" as the real function name in source code? The __unDName() function in msvcrt (and its younger sibling, __unDNameEx()). The undname tool included with Visual Studio will call this function for you on a name you give on the command line. Chip
Re: Vincent Povirk : windowscodecs: Add wrapper functions for IWICPalette methods.
On May 10, 2012, at 1:17 PM, Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 2fc7cdc93f6dc8ed67498b74193423c44e5bb770 > URL: > http://source.winehq.org/git/wine.git/?a=commit;h=2fc7cdc93f6dc8ed67498b74193423c44e5bb770 > > Author: Vincent Povirk > Date: Tue May 8 10:49:22 2012 -0500 > > windowscodecs: Add wrapper functions for IWICPalette methods. I have to say, these patches all seem really mechanical. Correct me if I'm wrong, but I think MIDL has an option to generate the proxy wrappers automatically. Even if it doesn't, I'm sure this would be a good feature to add to widl (if we don't already have it) so we don't have to laboriously write and maintain each and every one of the proxy wrappers. Chip
Re: [5/5] msvcm80: Add __setusermatherr_m stub.
On May 4, 2012, at 10:10 AM, Vincent Povirk wrote:
> diff --git a/dlls/msvcm80/msvcm80_main.c b/dlls/msvcm80/msvcm80_main.c
> index cd38f5b..eb09898 100644
> --- a/dlls/msvcm80/msvcm80_main.c
> +++ b/dlls/msvcm80/msvcm80_main.c
> @@ -50,3 +50,10 @@ void __cdecl
> CrtImplementationDetails_RegisterModuleUninitializer(void* handler)
> FIXME("%p: stub\n", handler);
> }
>
> +/* handler is a "method" with signature int32 (*handler)(_exception*), but
> I'm
> + * not sure what that means */
I am. Actually, it's:
int (__clrcall *handler)(struct _exception *)
i.e. a "pointer to a function intended to be called from managed code that
takes a pointer to a struct _exception and returns an int." The definition of
struct _exception is in under Visual Studio.
To write such a function, you'd need a C++/CLI compiler.
Chip
Re: [2/5] msvcm80: Add stub dll.
On May 4, 2012, at 11:36 AM, Stefan Dösinger wrote: > Am Freitag, 4. Mai 2012, 11:07:50 schrieb Vincent Povirk: >> + * Copyright 2010 Vincent Povirk for CodeWeavers > Your clock seems a bit slow. > I imagine that he started working on this a while ago. Maybe he does have a plan for finishing this... Chip
Re: [2/5] msvcm80: Add stub dll.
On May 4, 2012, at 10:07 AM, Vincent Povirk wrote: > > <0002-msvcm80-Add-stub-dll.txt> msvcmrt? The Managed C++ Runtime DLL? I imagine you won't get far on that without a C++/CLI compiler that understands the Microsoft Visual C++ ABI--unless you're willing to write all the marshaling glue code by hand. There's only one such compiler right now, and it only runs on Windows. VC++ ABI support is on my Clang to-do list--heck, it's my GSoC project--but C++/CLI is something I won't get to for a while. Given all that, how do you intend to implement this? Chip
SoC 2012 Ideas
Hi, Since I graduate this year, this may be the last time I participate--or at least, attempt to participate, since last year didn't quite work out for me :(--in Summer of Code. (I realize I was supposed to email you last week, but what's done is done.) So, without further ado, here's what I'm proposing: 1) Make Wine use App Sandbox on Mac OS X. A project that used to be listed on the SoC ideas page was to implement proper sandboxing in Wine. Apparently, you think this is unrealistic, because you took it down. (Not the page, just that suggestion.) But, I think that if I narrowed my focus a bit, it could be possible to do this. I'm proposing using the Mac OS App Sandbox API--the beginnings of which were introduced in 10.5 and which came into its own in 10.7--to improve security of Wine on Mac OS. Wine is an excellent candidate for the App Sandbox, because most of its file-system activity is limited to a single directory--namely, the Wine prefix. I'm not sure what you think of this, though, so I'm throwing this out there to get feedback. At the very least, I would like to be able to limit Wine's file-system activity to the prefix. 2) HLSL compiler. Well, my D3D bytecode backend to LLVM didn't pan out like I'd hoped. Maybe an LLVM-based compiler is too complex for Wine right now. But perhaps we don't need it right now anyway. If CodeWeavers can't afford to pay me, maybe Google can. I can add a simple parser and compiler (that performs little or no optimization) that hopefully would be sufficient for Wine's purposes. 3) Integrate pieces of DCE/RPC into Wine. As you may or may not know, in Mac OS 10.7, Apple stopped using Samba (probably because it uses the GPL3 as its license) in favor of their own implementation--which just so happens to be based on the original DCE/RPC implementation (the same one that was used as a base for MS RPC). I figured we could cannibalize pieces of it for our own use. Or is that not acceptable? What do you think? I'm not sure how useful or feasible these are, so I'm posting to the list before. Chip
Re: [PATCH] mscoree: Print the correct values in a TRACE.
On Mar 23, 2012, at 3:09 PM, Nicolas Le Cam wrote:
> Le 23 mars 2012 21:41, Lauri Kenttä a écrit :
>> ---
>> dlls/mscoree/mscoree_main.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/dlls/mscoree/mscoree_main.c b/dlls/mscoree/mscoree_main.c
>> index 1aa120f..0ebc813 100644
>> --- a/dlls/mscoree/mscoree_main.c
>> +++ b/dlls/mscoree/mscoree_main.c
>> @@ -359,7 +359,7 @@ HRESULT WINAPI GetRequestedRuntimeInfo(LPCWSTR pExe,
>> LPCWSTR pwszVersion, LPCWST
>>
>> HRESULT WINAPI GetRequestedRuntimeVersion(LPWSTR pExe, LPWSTR pVersion,
>> DWORD cchBuffer, DWORD *dwlength)
>> {
>> -TRACE("(%s, %p, %d, %p)\n", debugstr_w(pExe), debugstr_w(pExe),
>> cchBuffer, dwlength);
>> +TRACE("(%s, %p, %d, %p)\n", debugstr_w(pExe), pVersion, cchBuffer,
>> dwlength);
>>
>> if(!dwlength)
>> return E_POINTER;
>> --
>> 1.7.9.4
>>
>>
>>
> Hi Lauri,
>
> Should be %s debugstr_w(pVersion) IMHO.
No, that's an out parameter. (It's hard to tell, because the in parameter pExe
is of type LPWSTR instead of LPCWSTR.)
Chip
Re: Are we the reason Apple isn't helping us?
Sorry about the really long email, but I didn't want to flood your inboxes with 5 separate responses. On Mar 11, 2012, at 12:15 AM, Jerome Leclanche wrote: > On Sun, Mar 11, 2012 at 4:33 AM, Charles Davis > wrote: >> Hi, >> >> An Apple developer recently contacted me directly about the Wine64 radar >> (number 9269783). What's interesting about his response, however, is that he >> put in an aside to berate us for our etiquette. I am convinced that at least >> this developer sees us as rude, hateful creatures now, and he cited a >> particular bug (29922) that he filed and even offered to fix as an example. >> Gee, I wonder why that might be? (Hint: Look at the "To:" field.) >> >> In your defense, I realize that Vitaliy's behavior is not representative of >> Wine developers as a whole, and that Jeremy's behavior wasn't exactly >> golden, either. I also realize that there really is no build breakage >> resulting from the bug, because we don't include any Objective-C headers. He >> was convinced that there could have been breakage, however. You--AJ, I'm >> talking to you in particular--did not adequately explain to him why this >> didn't break the build. Instead, you--Vitaliy in particular--practically >> yelled at him--for trying to help! By this point, he's likely told his >> colleagues at Apple about his experience. With guys like Vitaliy developing >> Wine, is it any wonder Apple doesn't want to help? Are we, the developers, >> the real reason Apple isn't contributing? For that matter, are we the real >> reason more people *in general* aren't contributing? >> >> At the very least, we should be more welcoming of help, even from Apple. We >> need it. Maybe not to fix trivial non-bugs like 29922, but to make Wine a >> better alternative to Windows--on Mac, Linux, or anywhere. But as long as >> people like Vitaliy are yelling at potential contributors, we won't get much >> help beyond what we've got at CodeWeavers. >> >> Just my two bits. >> >> Chip >> > > There are a thousand bugs where I would agree with you, but Jeremy's second > post was "I don't plan on submitting patches to you frequently enough to make > it worth my time to read your policies and subscribe to your lists.". That's > not "trying to help", it's self-entitled behaviour. True. But my original point--that Vitaliy was unnecessarily rude to our guest--stands. > > I do think there is unnecessary rudeness floating around bugzilla in general > though. It sometimes feel like some people's motto is to close as many bugs > invalid as they can, without even giving the user a chance to explain > themselves better. I've especially seen some non-native English speakers > filing very weird bugs and being yelled at "read this massive rules page" > when they could barely understand five words. > Now I realise some people's time is limited, unpaid, etc. But that's just it > -- no one (to my knowledge) is forced to take care of those users. I'm > personally doing bugzilla maintenance because it's fun for me to see a > project evolve; if I see an user that annoys me personally, I just leave it > and I know someone else (eg. Austin) will take care of them... if not, > silence is better than rudeness. I agree wholeheartedly. On Mar 11, 2012, at 9:01 AM, Henri Verbeet wrote: > While I'm inclined to agree on the general point that some of the > replies on bugzilla aren't the most tactful or effective way to get a > point across, I don't think it has a whole lot to do with Apple > helping Wine or not. I know that at CodeWeavers we've filed a fair > amount of bugs in the Apple bug tracker, often with detailed > descriptions and test cases to reproduce them. Most of the time those > just get (very politely, true) ignored. My impression is that the > reasons are mostly political, but that's of course something that's > hard to substantiate. I suspect you are right. In fact, I know that when Steve Jobs came back to Apple, one of the first things he did was to convince Microsoft to invest money in them. So, I don't know if that's true today, but I know that at one point Microsoft owned a sizable chunk of Apple. If it is still true, I suspect that is the major reason Apple chooses not to help more. On Mar 11, 2012, at 11:50 AM, Ralph Little wrote: > The Wine developers know nothing about me and my experience. I have attempted > to demonstrate that, although I lack much time, I am prepared to put some > effort into helping where I c
Are we the reason Apple isn't helping us?
Hi, An Apple developer recently contacted me directly about the Wine64 radar (number 9269783). What's interesting about his response, however, is that he put in an aside to berate us for our etiquette. I am convinced that at least this developer sees us as rude, hateful creatures now, and he cited a particular bug (29922) that he filed and even offered to fix as an example. Gee, I wonder why that might be? (Hint: Look at the "To:" field.) In your defense, I realize that Vitaliy's behavior is not representative of Wine developers as a whole, and that Jeremy's behavior wasn't exactly golden, either. I also realize that there really is no build breakage resulting from the bug, because we don't include any Objective-C headers. He was convinced that there could have been breakage, however. You--AJ, I'm talking to you in particular--did not adequately explain to him why this didn't break the build. Instead, you--Vitaliy in particular--practically yelled at him--for trying to help! By this point, he's likely told his colleagues at Apple about his experience. With guys like Vitaliy developing Wine, is it any wonder Apple doesn't want to help? Are we, the developers, the real reason Apple isn't contributing? For that matter, are we the real reason more people *in general* aren't contributing? At the very least, we should be more welcoming of help, even from Apple. We need it. Maybe not to fix trivial non-bugs like 29922, but to make Wine a better alternative to Windows--on Mac, Linux, or anywhere. But as long as people like Vitaliy are yelling at potential contributors, we won't get much help beyond what we've got at CodeWeavers. Just my two bits. Chip
Re: [PATCH] winepulse: Add pulse driver, v8
On Feb 28, 2012, at 10:58 PM, Chris Robinson wrote: > On Tuesday, February 28, 2012 5:32:13 PM Maarten Lankhorst wrote: >> + * This is basically the same as the pa_threaded_mainloop implementation, >> + * but that cannot be used because it uses pthread_create directly >> + * >> + * pa_threaded_mainloop_(un)lock -> pthread_mutex_(un)lock >> + * pa_threaded_mainloop_signal -> pthread_cond_signal >> + * pa_threaded_mainloop_wait -> pthread_cond_wait > > I'm curious why you're using pthreads. Doesn't WinAPI have anything > comparable > to pthread_cond_wait? It does: http://msdn.microsoft.com/en-us/library/ms686301(v=vs.85).aspx For some reason, the condition variable API just hasn't been implemented in Wine yet. Chip
Re: Alexandre Julliard : gdi32: Avoid overflows for invalid coordinates in line clipping.
On Feb 22, 2012, at 1:27 PM, Alexandre Julliard wrote:
> --- a/dlls/gdi32/dibdrv/objects.c
> +++ b/dlls/gdi32/dibdrv/objects.c
> @@ -372,7 +372,8 @@ static inline DWORD calc_outcode(const POINT *pt, const
> RECT *clip)
> int clip_line(const POINT *start, const POINT *end, const RECT *clip,
> const bres_params *params, POINT *pt1, POINT *pt2)
> {
> -int m, n;
> +
> +INT64 m, n; /* 64-bit to avoid overflows (FIXME: find a more efficient
> way) */
What about MulDiv()? As I recall, this is the sort of situation for which it
was designed. Or is that not efficient?
Chip
Re: Windows-on-Arm won't support win32
On Feb 13, 2012, at 7:09 PM, Dan Kegel wrote: > On Mon, Feb 13, 2012 at 4:36 PM, Charles Davis > wrote: >> >> ...our implementation can be written purely in C the same way all our COM >> DLLs are. > > Or, come to think of it, we could write in Mono. True, but do we really want a hard dependency on Mono? (I know we already have a soft one, but from what I can tell from wine-users, it doesn't seem to work very well for running .NET apps.) >> As an aside, I actually started working on that precisely so Wine could use >> it :). > > How far along is it? Not very far at all, actually. I worked a bit on name mangling and 64-bit EH, and someone else is working on class layouts, but it's far from usable. Part of the problem is that I haven't had much time to work on it. Chip
Re: Windows-on-Arm won't support win32
On Feb 13, 2012, at 3:20 PM, Dan Kegel wrote: > According to > http://www.zdnet.com/blog/perlow/the-long-kiss-goodbye-for-x86-desktop-windows/19840 > Microsoft is not letting developers use win32 on arm (although > Microsoft is probably using it themselves for Office on arm). > Instead, native apps have to use WinRT, a C++-based class library. As others have pointed out, that's not entirely true. Yes, it's probably written in C++. Yes, two of the interfaces to this are C++ class libraries, one of which requires a special version of C++ (dubbed C++/CX by MS). But WinRT itself is not a C++ class library; it's a COM library with a few extensions to COM. And that means... > > If it takes off, and someone feels like supporting it in Wine, > they would probably have to start by implementing the first > bits in C like wine's msvcp support. ...our implementation can be written purely in C the same way all our COM DLLs are. But that's if it takes off. And I don't see that happening. Personally, I think we should be putting our already strained resources into improving compatibility with Win32. With Microsoft apparently ready to all but abandon Win32, Wine will be more important than ever as a way to run legacy apps that aren't based on WinRT. > Eventually, if and when llvm gets Visual C++ ABI support, > maybe wine could start allowing C++ source code. > > (FWIW, I see Charles Davis was working on that, > http://code.google.com/p/google-summer-of-code-2010-llvm/updates/list > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-March/014305.html > https://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp > ). As an aside, I actually started working on that precisely so Wine could use it :). Chip
Re: [PATCH 3/7] ntdll: fix endianness of three fields in DVD_LAYER_DESCRIPTOR (resend)
On Feb 10, 2012, at 4:24 PM, Dan Kegel wrote: > On Fri, Feb 10, 2012 at 2:00 PM, Charles Davis > wrote: >>> -p->StartingDataSector = l->start_sector; >>> -p->EndDataSector = l->end_sector; >>> -p->EndLayerZeroSector = l->end_sector_l0; >>> +p->StartingDataSector = GET_BE_DWORD(l->start_sector); >>> +p->EndDataSector = GET_BE_DWORD(l->end_sector); >>> +p->EndLayerZeroSector = GET_BE_DWORD(l->end_sector_l0); >> I don't know about this. To make your original patch work right on Mac, one >> of the things I had to do was get rid of the OSReadBigInt32() calls that >> swapped the endianness of the sector fields from big to host. > > This was needed for Dragon Age Origins able to detect its disc, see > http://bugs.winehq.org/show_bug.cgi?id=29667 > That's our source of truth, I guess. Huh. I guess then that's a problem with your test program, which fails because the descriptor returned from SCSI pass-through (at least, on Mac) has those fields in big-endian order, but the descriptor returned from the IOCTL has them in host order, and the test program compares them directly without swapping one or the other. > Do you have a copy of Dragon Age > handy to test with? No, not for Windows, anyway. I have plenty of other DVD games, though. Chip
Re: [PATCH 3/7] ntdll: fix endianness of three fields in DVD_LAYER_DESCRIPTOR (resend)
On Feb 10, 2012, at 1:30 PM, Dan Kegel wrote:
> ---
> dlls/ntdll/cdrom.c | 12 +---
> 1 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/dlls/ntdll/cdrom.c b/dlls/ntdll/cdrom.c
> index 802782b..6b64203c 100644
> --- a/dlls/ntdll/cdrom.c
> +++ b/dlls/ntdll/cdrom.c
> @@ -144,6 +144,12 @@ WINE_DEFAULT_DEBUG_CHANNEL(cdrom);
> # define CD_FRAMES75 /* frames per second */
> #endif
>
> +#ifdef WORDS_BIGENDIAN
> +#define GET_BE_DWORD(x) (x)
> +#else
> +#define GET_BE_DWORD(x) RtlUlongByteSwap(x)
> +#endif
> +
> static const struct iocodexs
> {
> DWORD code;
> @@ -2568,9 +2574,9 @@ static NTSTATUS DVD_ReadStructure(int dev, const
> DVD_READ_STRUCTURE *structure,
> p->Reserved1 = 0;
> p->TrackDensity = l->track_density;
> p->LinearDensity = l->linear_density;
> -p->StartingDataSector = l->start_sector;
> -p->EndDataSector = l->end_sector;
> -p->EndLayerZeroSector = l->end_sector_l0;
> +p->StartingDataSector = GET_BE_DWORD(l->start_sector);
> +p->EndDataSector = GET_BE_DWORD(l->end_sector);
> +p->EndLayerZeroSector = GET_BE_DWORD(l->end_sector_l0);
I don't know about this. To make your original patch work right on Mac, one of
the things I had to do was get rid of the OSReadBigInt32() calls that swapped
the endianness of the sector fields from big to host.
Chip
> p->Reserved5 = 0;
> p->BCAFlag = l->bca;
> p->Reserved6 = 0;
> --
> 1.7.9
>
>
>
Re: [PATCH 4/7] kernel32/tests: initial tests for cdrom.c (try 2)
On Feb 10, 2012, at 1:30 PM, Dan Kegel wrote:
> +START_TEST(cdrom)
> +{
[...]
> +/* GENERIC_WRITE because without it, passthrough doesn't work on win7 */
But with it, you can't open the device at all on Mac. As I explained on bug
29669, the device file only has 0440 access.
Chip
Re: Wine automated testing update
On Feb 3, 2012, at 10:13 AM, Jeremy White wrote: > On 02/03/2012 10:47 AM, Dan Kegel wrote: >> Jeremy wrote: >>> the VMWare folks are not willing to provide a permanent license for VMWare >>> to us. >>> >>> So, we've shifted gears, and are exploring whether something like qemu + >>> kvm would be a sufficient alternate. >> >> What's the plan for automated MacOSX testing? I hear 10.7 >> supports running in a VM... > > No plan at all, which is an oversight. > > I think we may have to have a 'real' Windows box to do any kind of > credible D3D tests; perhaps we have to make the same argument for Mac > OSX. But boy it sure would be nice if we could put MacOSX into a VM... Yeah... Trouble is, you need to run it on a Mac anyway. (The host OS doesn't have to be Mac OS, but it has to be running on Mac hardware.) At least, that's my understanding of Apple's SLA for Mac OS X. I have a launchd.plist (a config file for the Mac OS launcher daemon, their version of init, inetd, and cron all rolled into one) and a set of scripts that runs the tests every night after AJ commits. I've attached them here. The scripts expect to be run from the directory containing the Wine sources. The configuration is specific to my system (i.e. all the paths refer to directories in my home folder)--if anyone wants to use it, you'll have to change it for your system. Also note that the log file it produces needs to be turned over manually--this is because launchd handles setting the stdout and stderr paths to this file, and by the time my scripts can get around to removing it, the file is already open. Finally, when you activate the script, you must remember to set the DISPLAY variable in launchd's environment (launchctl setenv DISPLAY "$DISPLAY"). By the way, I still want to make my box into a buildslave. Though now I'm thinking about making my old MacBook Pro into a slave, instead of my Mac Pro which gets used a lot nowadays. Chip wine-test-mac.tar.bz2 Description: BZip2 compressed data > > Cheers, > > Jeremy > >
Re: [PATCH] kernel32: implement GetLogicalProcessorInformation
On Nov 25, 2011, at 8:17 AM, Claudio Fontana wrote: > On Fri, Nov 25, 2011 at 4:07 PM, Claudio Fontana > wrote: >> I have resent the patch as a "try 2" (there was a try 1.5 to fix test >> issues under windows older than XP SP3). >> >> The patch contains changes based on your feedback. > > Which is completely broken, since the U() macro you suggested to use > is a wine/test.h feature only, > and completely broke the patch. You are right. The way most files (other than tests) in Wine deal with that is that they unconditionally define NONAMELESSUNION and NONAMELESSSTRUCT. So you wouldn't use U(buffer[i]) (except in the tests, where you can do that), you'd use buffer[i].u . > So I fall back to my try 1.5 for my tree. OK, you do that. I'm pretty sure AJ won't take your patch anyway until it's done "right" (i.e. like I said, in ntdll). I guess I'll take that up, since I have nothing better to do ;). Chip
Re: [PATCH] kernel32: implement GetLogicalProcessorInformation
Hi,
On Nov 24, 2011, at 4:21 AM, Claudio Fontana wrote:
> First implementation of GetLogicalProcessorInformation.
> Limitations: all logical processors are added to the same NUMA set,
> and all cores are added to the same package.
> Only the linux-specific helper function is implemented, so for now
> everybody else gets the fallback hard-coded results only.
> The fallback is also triggered when the OS-specific APIs fail.
>
> The linux-specific function is based on sysfs.
>
> The new OS-specific functions can be easily added as additional
> ifdefs by following the linux example.
> ---
> dlls/kernel32/process.c | 350 ++-
> dlls/kernel32/tests/Makefile.in |1 +
> dlls/kernel32/tests/glpi.c | 82 +
You should really implement this in ntdll.NtQuerySystemInformation (information
class SystemLogicalProcessorInformation). In general, kernel32 forwards most of
its implementation to ntdll, which reduces code duplication.
> 3 files changed, 430 insertions(+), 3 deletions(-)
> create mode 100644 dlls/kernel32/tests/glpi.c
IMO, you should add the test to dlls/ntdll/tests/info.c, and test
NtQuerySystemInformation() with info class SystemLogicalProcessorInformation.
>
> diff --git a/dlls/kernel32/process.c b/dlls/kernel32/process.c
> index b6c0b9d..de39244 100644
> --- a/dlls/kernel32/process.c
> +++ b/dlls/kernel32/process.c
> @@ -51,6 +51,12 @@
>
> #include "ntstatus.h"
> #define WIN32_NO_STATUS
> +
> +#include "windef.h"
> +#include "winbase.h"
> +#include "winerror.h"
> +#include "winnt.h"
> +
> #include "winternl.h"
> #include "kernel_private.h"
> #include "psapi.h"
> @@ -3705,14 +3711,352 @@ HANDLE WINAPI GetCurrentProcess(void)
> return (HANDLE)~(ULONG_PTR)0;
> }
>
> +/***
> + * glpi_impl_fb:
> + * a fallback implementation of GetLogicalProcessorInformation
> + * for the systems we do not support yet,
> + * or for when the OS-specific API fails.
> + * Same arguments and return value as glpi.
> + */
This comment should really come right before the function you're documenting.
Also, it's formatted wrong. It should look more like this:
/***
*logical_processor_info_fallback
*
* Fallback implementation of NtQuerySystemInformation() with info class
* SystemLogicalProcessorInfo.
*/
> +
> +#undef SLPI
> +#ifdef NONAMELESSUNION
> +#define SLPI(buffer, idx) buffer[idx].DUMMYUNIONNAME
> +#else
> +#define SLPI(buffer, idx) buffer[idx]
> +#endif /* NONAMELESSUNION */
You could avoid the ifdef if you used the U() macro. In fact, why are you
defining a macro at all? Just use U(buffer[idx]).
> +
> +static BOOL
> +glpi_impl_fb(PSYSTEM_LOGICAL_PROCESSOR_INFORMATION buffer, PDWORD pbuflen)
Surely you could use a more descriptive name. (See one example in my example
doc comment.) This isn't 1978, you know.
> +{
> +int glpi_n = 5;
> +FIXME("(%p,%p): reporting hard coded information\n", buffer, pbuflen);
> +
> +if (*pbuflen < sizeof(*buffer) * glpi_n)
> +{
> + SetLastError(ERROR_INSUFFICIENT_BUFFER);
> + *pbuflen = sizeof(*buffer) * glpi_n;
> + return FALSE;
> +}
> +
> +buffer[0].ProcessorMask = (ULONG_PTR)0x01;
> +buffer[1].ProcessorMask = (ULONG_PTR)0x01;
> +buffer[2].ProcessorMask = (ULONG_PTR)0x01;
> +buffer[3].ProcessorMask = (ULONG_PTR)0x01;
> +buffer[4].ProcessorMask = (ULONG_PTR)0x01;
These casts aren't necessary.
> +
> +buffer[0].Relationship = RelationProcessorCore;
> +buffer[1].Relationship = RelationNumaNode;
> +buffer[2].Relationship = RelationCache;
> +buffer[3].Relationship = RelationCache;
> +buffer[4].Relationship = RelationProcessorPackage;
> +
> +SLPI(buffer, 0).ProcessorCore.Flags = (BYTE)0x00;
> +SLPI(buffer, 1).NumaNode.NodeNumber = (DWORD)0x00;
Neither are these.
> +
> +SLPI(buffer, 2).Cache.Level = (BYTE)0x01;
> +SLPI(buffer, 2).Cache.Associativity = (BYTE)0x08;
> +SLPI(buffer, 2).Cache.LineSize = (WORD)64;
> +SLPI(buffer, 2).Cache.Size = (DWORD)16 << 10; /* 16 KB */
Or these.
> +SLPI(buffer, 2).Cache.Type = CacheData;
> +
> +SLPI(buffer, 3).Cache.Level = (BYTE)0x02;
> +SLPI(buffer, 3).Cache.Associativity = (BYTE)0x08;
> +SLPI(buffer, 3).Cache.LineSize = (WORD)64;
> +SLPI(buffer, 3).Cache.Size = (DWORD)1024 << 10; /* 1024 KB */
Or these.
> +SLPI(buffer, 3).Cache.Type = CacheUnified;
> +/* no additional info for processor package at buffer[4] needed. */
> +
> +*pbuflen = sizeof(*buffer) * glpi_n;
> +return TRUE;
> +}
> +
> +#ifdef linux
> +/**
> + * glpi_impl_linux:
> + * an implementation of GetLogicalProcessorInformation
> + * for linux sysfs.
> + * Returns: -1 on API failure (trigger fallback),
> + * otherwise see glpi.
> + */
See above.
> +
> +#define SYS_CPU "/sys/devices/system/cpu/cpu"
> +#define SYS_CPU_MAX 63
I'd criticize your use of a static limit, if onl
Re: [PATCH] server: Use syscall(2) instead of inline assembly on Mac OS, too.
On Oct 9, 2011, at 1:42 PM, David Laight wrote:
> On Sat, Oct 08, 2011 at 07:48:40PM +0200, Alexandre Julliard wrote:
>> Charles Davis writes:
>>
>>> @@ -268,9 +256,9 @@ int send_thread_signal( struct thread *thread, int sig )
>>> if (!mach_port_extract_right( process_port, thread->unix_tid,
>>> MACH_MSG_TYPE_COPY_SEND, &port, &type
>>> ))
>>> {
>>> -if ((ret = pthread_kill_syscall( port, sig )) < 0)
>>> +if ((ret = syscall( SYS___pthread_kill, port, sig )) != 0)
>>> {
>>> -errno = -ret;
>>> +errno = ret;
>>
>> syscall is supposed to take care of errno.
>
> I'm also not at all sure of the portability of using syscall() in
> application code.
>
> What happens when you try to run the above on anything other than Linux?
> (Eg aone of the BSDs)
That's just it. None of that code is portable. It was designed specifically to
work on Darwin (Mac OS X/iOS). (It was even worse before. It used x86 assembly
to make the syscall, so it would only work on an Intel Mac--and only in 32-bit
mode at that. So if anything, this is making it *more* portable.) It doesn't
get compiled anywhere else anyway. For this particular file, the only other
system I would be worried about is the HURD (the only other OS I know of that's
based on Mach), which hardly anyone uses in practice anyway.
Also, if you'll look at Wine's development history, you'll notice similar
patches by Maarten Lankhorst and, yes, by AJ himself, for Linux.
Chip
Re: [PATCH] server: Use syscall(2) instead of inline assembly on Mac OS; too.
On Oct 7, 2011, at 1:50 PM, Dan Kegel wrote: > Probably a spurious failure Yeah... especially considering that: - That change only affects Mac OS X, and I haven't added my buildslave yet ;). (That file shouldn't even get built on non-Darwin.) - Wine won't even build 64-bit on Mac OS yet (and might never). Chip > - I was running rpcrt4 tests on > that machine, and they may both have wanted the same port number. > Shame on me. > > On Fri, Oct 7, 2011 at 12:48 PM, Dan Kegel wrote: >> Fails tests on x86_64? >> >> On Fri, Oct 7, 2011 at 11:52 AM, wrote: >>> This is an experimental automated build and test service. >>> Please feel free to ignore this email while we work the kinks out. >>> >>> For more info about this message, see http://wiki.winehq.org/BuildBot >>> >>> The Buildbot has detected a failed build on builder runtests-default-x86_64 >>> while building Wine. >>> Full details are available at: >>> http://buildbot.kegel.com/builders/runtests-default-x86_64/builds/35 >>> (though maybe not for long, as I'm still reinstalling the buildbot >>> periodically while experimenting) >>> BUILD FAILED: failed shell_3 >>> >>> Errors: >>> alarum: failed command was ../../../wine rpcrt4_test.exe.so rpc.c >>> fixme:rpc:RpcNetworkIsProtseqValidW Unknown protseq L"foo" >>> err:rpc:rpcrt4_protseq_ncacn_ip_tcp_open_endpoint couldn't listen on port >>> 4114 >>> rpc.c:238: Test failed: RpcServerUseProtseqEp failed (1740) >>> fixme:rpc:RpcBindingInqAuthInfoExW authorization service not implemented >>> make: *** [rpc.ok] Error 1 >>> >>> >>
Re: kernel32: Implement GetVolumePathName.
On Oct 4, 2011, at 11:56 AM, Erich Hoover wrote: > On Tue, Oct 4, 2011 at 11:36 AM, Charles Davis > wrote: >> On Oct 4, 2011, at 9:32 AM, Erich Hoover wrote: >>> This patch implements GetVolumePathName by using the full folder >>> path and working backward until stat() returns a different device. >> Surely there's a better way. Can't you do a statfs(2)/statvfs(2) (for >> example) to find out the FS root? (I know that works on the BSDs and Mac OS, >> because their statfs/statvfs structures all have a field for >> that--f_mntonname.) Then you can map that path back to a Wine path, and >> return that. Of course, that won't work for fake drives (see below). > > I doubt it, the function needs to return the mount point along the > given path (see MSDN). In the case of cross-device symbolic links > your suggestion will not return the current path. Ah, you're right. MSDN says that GetVolumePathName() returns the volume containing the target of the symlink... unless of course, the path is a remote one. (Same for mounted volumes.) But that isn't a common case, nor is it one that Wine even supports yet :). > >> At the very least, you should be caching this information, like I did when I >> added case-insensitive lookup support to Wine (see commit >> 4e44e153c5c78339f17baeabe22f2015cfc8737c). Because you call stat(2) on every >> single directory in a pathname (especially in the common case of the file >> being on the root device), calculating this from scratch is extremely >> expensive. > > I'm not sure this function is used enough to justify caching the > results, as this is the first time I've noticed the FIXME on the > console. If someone thinks that is the case then I can always make > that a "part 2" patch. OK. > >> And what about drive C? On Wine, that's not a device at all. It's a folder >> usually somewhere on the root device. In general, I don't see anything in >> your patch that accounts for fake drives like C:--the common case, I might >> add! > > If you pass it just the path to "C:\" then it will spit back "C:\", > since it only encounters the one filesystem. If you pass something > like "C:\windows\system32\" then it will spit back "C:\" unless the > "windows" or "system32" folders are symbolic links to a folder on > another drive. Ah, I read your patch wrong. Never mind. Chip
Re: kernel32: Implement GetVolumePathName.
On Oct 4, 2011, at 9:32 AM, Erich Hoover wrote: > This patch implements GetVolumePathName by using the full folder > path and working backward until stat() returns a different device. Surely there's a better way. Can't you do a statfs(2)/statvfs(2) (for example) to find out the FS root? (I know that works on the BSDs and Mac OS, because their statfs/statvfs structures all have a field for that--f_mntonname.) Then you can map that path back to a Wine path, and return that. Of course, that won't work for fake drives (see below). At the very least, you should be caching this information, like I did when I added case-insensitive lookup support to Wine (see commit 4e44e153c5c78339f17baeabe22f2015cfc8737c). Because you call stat(2) on every single directory in a pathname (especially in the common case of the file being on the root device), calculating this from scratch is extremely expensive. And what about drive C? On Wine, that's not a device at all. It's a folder usually somewhere on the root device. In general, I don't see anything in your patch that accounts for fake drives like C:--the common case, I might add! Chip
Re: Tests failing on OSX
On Sep 21, 2011, at 3:35 PM, Stefan Dösinger wrote: > On Wednesday 21 September 2011 02:29:31 Charles Davis wrote: >>> No Xvidmode support, so Get/SetDeviceGammaRamp fail. There's a win_skip >>> for that already. Should we change it to skip(), or ignore it until we >>> have a quartz driver? >>> User32/monitor also fails because it can't change the display mode. >> >> Key words: "stock X11 server". XQuartz has much better support for this. >> You should be using that. > Indeed, Xquartz supports Xrandr these days. Unfortunately the GammaRamp tests > still fail. Either There's no Xvidmode(afaik there's no gamma in xrandr), or > it doesn't work. I thought Xrandr 1.2 and up supported gamma control (see XRRCrtcGamma struct and XRR*Gamma functions in ). > > I also wondered if Xquartz brings it's own X11 headers and libraries. I > haven't found any, so I'm still using /usr/X11/include and /usr/X11/bin. Xquartz puts its include and lib files in /opt/X11/include and /opt/X11/lib, respectively. Chip
Re: Tests failing on OSX
On Sep 20, 2011, at 3:11 PM, Stefan Dösinger wrote: >> gdi32/dc >> user32/monitor > No Xvidmode support, so Get/SetDeviceGammaRamp fail. There's a win_skip for > that already. Should we change it to skip(), or ignore it until we have a > quartz driver? > User32/monitor also fails because it can't change the display mode. Key words: "stock X11 server". XQuartz has much better support for this. You should be using that. > >> kernel32/change >> ntdll/change >> ntdll/directory > Lots of test failures. I'm not sure what those tests do tbh I wrote a message to the list about fixing those tests once. The problem is that the functionality they test (well, at least the */change tests) isn't implemented on Mac. And none of our options for implementing it look good (c.f. "Failing kernel32:change and ntdll:change tests on Mac OS"). > >> ntdll/exception > "Test failed: Execution of data memory succeeded." Do I have to do anything > special to enable NX support on OSX? No. It's just that the kernel for some reason only supports NX on stacks in 32-bit code. They fixed it in Mac OS 10.7. > >> mmdevapi/capture > Various Set*Volume calls fail I know that some CoreAudio devices actually don't have software volume controls. Optical out, for example. For these devices, Set*Volume will always fail. Not sure if that's what 's happening in your case, though. >> ws2_32/sock > A mixture of test failures and unexpected successes. >From what I can tell, Wine's WinSock implementation seems to depend on several >nuances of Linux's BSD sockets implementation that are different from the >original 4.xBSD implementation (from which most others, including WinSock >itself, are derived). Hope that helps. Chip
Re: Glitch-free iTunes?
On 7/5/11 2:23 AM, Damjan Jovanovic wrote: > On Tue, Jul 5, 2011 at 10:13 AM, Stefan Dösinger > wrote: >> Do we need full-fledged support for USB drivers for iTunes? I've been told in >> the past that all we need to do is properly report the new USB drive to >> iTunes >> when an iPod is attached, and can leave the USB mass storage handling to the >> Linuy OS. Of course "properly reporting" isn't as simple as creating a drive >> letter and setting its type to USB drive. >> >> I'm sorry to interrupt this nice project management discussion by throwing in >> a technical question :-) >> >> > > It used to work that way, but Dan Kegel's analysis of a recent version > of iTunes seems to indicate it now pulls in USBD.SYS. Maybe they > changed it or maybe they now do direct USB I/O in addition to going > through the mass storage interface? I have a Mac, and an iPod Touch. When I plug the iPod in, it doesn't show up as an external disk in the Finder. So on Mac, iTunes definitely does direct USB I/O. It's probably safe to assume it does on Windows, too. Chip
Re: [1/3] kernel32/heap: Emulate Win9x if appropriate in GlobalMemoryStatusEx(). (resend)
On 6/2/11 2:46 PM, Adam Martinson wrote: > On 06/02/2011 03:10 PM, Dmitry Timoshkov wrote: >> Adam Martinson wrote: >> >>> +osver.dwOSVersionInfoSize = sizeof(osver); >>> +GetVersionExW(&osver); >>> + >> ... >>> +if (osver.dwMajorVersion>= 5) >> Once again, that's wrong way of detecting win9x, or please try to explain >> better how the patch does what the subject describes, and for which app >> it's needed. >> > The stuff in that block is for win2k+ mode only. Win9x doesn't add > [Total|Avail]Phys to [Total|Avail]PageFile. If wine is in win9x mode it > should behave like win9x, or it confuses old apps. This is needed for > the 2nd patch, IIRC removing the photoshop 4 hack in > GlobalMemoryStatus() screws up programs like Adobe Illustrator 8 in > win98 mode without it. I guess what Dmitry is really trying to ask is: what about NT4? Its major version is less than 5, but it's not a Win9x-family OS; it's an NT-family OS.
Re: NTDLL doesn't compile under Clang
On 5/29/11 12:41 PM, C.W. Betts wrote:
> When compiling the NTDLL component of Wine, I get the following error:
> ../../../wine-git/./dlls/ntdll/large_int.c:267:13: error: unknown use of
> instruction mnemonic without a size suffix
> __asm__("div %4,%%eax"
> ^
> :1:2: note: instantiated into assembly here
> div 12(%esp),%eax
> ^
> I'm using Clang 2.0 from Xcode 4.0
That's a Clang bug that's already been fixed. Sadly, it didn't make it
into Xcode 4.0.
Chip
Re: no line numbers in backtraces on Mac OS X?
On 5/23/11 1:53 PM, Stefan Dösinger wrote: > On Monday 23 May 2011 17:48:55 Charles Davis wrote: >> Right now on Mac, you have to configure with -gstabs+. DbgHelp doesn't >> support DWARF on Mac OS yet. (It doesn't know how to find the .dSYM >> bundle or the original object files.) > Or you could just use gdb for debugging instead of winedbg. Just attach gdb > to > the running process. True, but gdb lacks information about PE-format modules that winedbg has. Chip
Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 7 resend)
On 5/23/11 12:15 PM, Alexandre Julliard wrote: > Charles Davis writes: > >> Rebased against Marcus Meissner's DECLSPEC_HIDDEN patches. (I hate you, >> Marcus...) >> Try 7: Fix getting the device name for IDE devices. >> Try 6: Fix some problems noticed by Vitaliy Margolen. >> Try 5: Get the value of "DeviceName" from mountmgr instead of making one up. >> Try 4: Fix unused variable warning. >> Try 3: Add support for IDE drives. >> Try 2: Don't depend on the SCSI generic driver on Linux. > > The unix device name is not being set properly here. I would consider > not setting the key a feature (we don't really need it), but it means > the DMA flag isn't set either. The problem is that Wine's winaspi/wnaspi32 is using the UnixDeviceName key. The way it uses it, it expects a SCSI generic device (/dev/sg*). That's why I set it to the /dev/sg* device if it's present, and don't set it otherwise. Most modern programs should be using SPTI instead of ASPI, though a few older programs from the Windows 9x era might still use ASPI. Do you want to rip out WinASPI support? Chip
Re: no line numbers in backtraces on Mac OS X?
On 5/23/11 9:44 AM, joerg-cyril.hoe...@t-systems.com wrote: > Hi, > > Is it normal that there are no source line numbers in backtraces on Mac OS? > Despite many patches to winedbg etc., the backtraces I get are > no better that those from 1.1.24 times. > 18 0x41f5b2a1 _OpenDriverA+0x51() in winmm (0x0032ce78) > 19 0x4041467f _initAudioDlg+0x75f() in winecfg (0x0032dc28) > > I'm using configure + make to build. On Linux, the line numbers help > a lot in locating bogus code. Right now on Mac, you have to configure with -gstabs+. DbgHelp doesn't support DWARF on Mac OS yet. (It doesn't know how to find the .dSYM bundle or the original object files.) > > Thank for your help, You're welcome. Chip
Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 6)
On 5/10/11 11:11 AM, Alexandre Julliard wrote: > Charles Davis writes: > >> Try 6: Fix some problems noticed by Vitaliy Margolen. >> Try 5: Get the value of "DeviceName" from mountmgr instead of making one up. >> Try 4: Fix unused variable warning. >> Try 3: Add support for IDE drives. >> Try 2: Don't depend on the SCSI generic driver on Linux. >> >> --- >> dlls/kernel32/Makefile.in|1 - >> dlls/kernel32/oldconfig.c| 404 >> -- >> dlls/kernel32/process.c |3 - >> dlls/mountmgr.sys/device.c | 192 - >> dlls/mountmgr.sys/diskarb.c |2 +- >> dlls/mountmgr.sys/hal.c | 207 +- >> dlls/mountmgr.sys/mountmgr.c |6 +- >> dlls/mountmgr.sys/mountmgr.h | 37 - >> 8 files changed, 439 insertions(+), 413 deletions(-) >> delete mode 100644 dlls/kernel32/oldconfig.c > > Now it's not setting DeviceName at all here. As far as I can tell, this is a limitation of the way mountmgr works. It only assigns a device name when a disk is in the drive. I take it you want me to fix that? Chip
Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 5)
On 5/9/11 8:36 AM, Vitaliy Margolen wrote:
> On 05/09/2011 07:42 AM, Charles Davis wrote:
>> Try 5: Get the value of "DeviceName" from mountmgr instead of making
>> one up.
>> Try 4: Fix unused variable warning.
>> Try 3: Add support for IDE drives.
>> Try 2: Don't depend on the SCSI generic driver on Linux.
>
>> -RtlCreateUnicodeStringFromAsciiz( &nameW, "FirstBusTimeScanInMs" );
>> +static const WCHAR bus_scan_timeW[] =
>> {'F','i','r','s','t','B','u','s','S','c','a','n','T','i','m','e','I','n','M','s',0};
>>
> These do not match.
You're right, will fix.
>
>>
>> +if (devtype)
>> +{
>> +if (!(type = p_libhal_device_get_property_string( ctx, udi,
>> "storage.drive_type",&error )))
>> +*devtype = ~0;
>> +else if (!strcmp( type, "disk" ) || !strcmp( type, "floppy" ))
>> +*devtype = 0x00;
>> +else if (!strcmp( type, "tape" ))
>> +*devtype = 0x01;
>> +else if (!strcmp( type, "cdrom" ))
>> +*devtype = 0x05;
>> +else if (!strcmp( type, "raid" ))
>> +*devtype = 0x0C;
>> +else
>> +*devtype = ~0;
>> +}
> Please don't use magic numbers here.
OK.
> Also these numbers are wrong. From
> winbase.h:
> #define DRIVE_UNKNOWN 0
> #define DRIVE_NO_ROOT_DIR 1
> #define DRIVE_REMOVABLE2
> #define DRIVE_FIXED3
> #define DRIVE_REMOTE 4
> /* Win32 additions */
> #define DRIVE_CDROM5
> #define DRIVE_RAMDISK 6
The numbers I used are actually the SCSI peripheral device type numbers.
I use them in create_scsi_entry() to figure out which one of the
"*Peripheral" strings to put in the registry. But yeah, I probably
shouldn't use magic numbers like that.
>
> Missing "DeviceName"="Cdrom0" for cdroms.
You only get a DeviceName if there's a disk in the drive (a limitation
of the way mountmgr works).
>
> Also names of devices do not match. This can potentially break some
> software:
> -"Identifier"="ATA Hitachi HDS72202JKAO"
> +"Identifier"="ATA Hitachi HDS72202"
> -"Identifier"="ATA WDC WD7500AAKS-030.0"
> +"Identifier"="ATA WDC WD7500AAKS-0"
OK, I can fix these.
> -"Identifier"="SAMSUNG DVDWBD SH-B083L SB01"
> +"Identifier"="SAMSUNG DVDWBD SH-B083L"
Can't fix that. HAL provides no way to query the SCSI revision of a SCSI
device. Short of actually sending an INQUIRY SCSI command to the device,
I don't know how to fix that.
Thanks.
Chip
Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 2)
On 4/25/11 5:01 AM, Alexandre Julliard wrote: > Charles Davis writes: > >> Try 2: don't depend on the existence of scsi-generic entries in the HAL tree. > > It's still not listing my /dev/hda CD drive. Hmm... which IDE driver is your kernel using, the "legacy" driver or the new libata-based driver? (I'm using libata, so that might account for what you're seeing.) Chip
Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32.
On 4/21/11 4:21 AM, Alexandre Julliard wrote: > Charles Davis writes: > >> On 4/20/11 9:43 AM, Alexandre Julliard wrote: >>> It doesn't seem to work here, I don't get any devices. >> Funny. It works fine on both my 32-bit and 64-bit VMs. Clearly my setup >> is broken :). >> >> By any chance, do you not have any SCSI generic (sg) files in /dev/? > > I don't, I have only hd and sd devices. That explains it. The patch used the SCSI generic entries on Linux, which aren't present if that support hasn't been compiled in/loaded. I'll rework the patch so it isn't so dependent on them. Chip
Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32.
On 4/20/11 9:43 AM, Alexandre Julliard wrote: > Charles Davis writes: > >> --- >> dlls/kernel32/Makefile.in|1 - >> dlls/kernel32/oldconfig.c| 404 >> -- >> dlls/kernel32/process.c |3 - >> dlls/mountmgr.sys/hal.c | 116 >> dlls/mountmgr.sys/mountmgr.c | 138 ++ >> dlls/mountmgr.sys/mountmgr.h |3 + >> 6 files changed, 257 insertions(+), 408 deletions(-) >> delete mode 100644 dlls/kernel32/oldconfig.c > > It doesn't seem to work here, I don't get any devices. Funny. It works fine on both my 32-bit and 64-bit VMs. Clearly my setup is broken :). By any chance, do you not have any SCSI generic (sg) files in /dev/? Chip
Re: Windres and wine
On 4/15/11 10:38 PM, Gerold Jens Wucherpfennig wrote: > Hi, > > I have created GUI dialog with ResEdit. > That rc-file shall be used in wine. > The problem is that wine doesn't have > a Windres.exe. Is it possible to make > a c-file from the rc-file? No. But you don't need windres. Wine has its own resource compiler (wrc). Chip
Introducing "Deobjectivizer"
Hi, I've been working on a secret Clang-based project for a while, and now I'm ready to share it with the world. Introducing the "Deobjectivizer". This is a program that scans framework bundle headers for Objective-C constructs, and generates procedural C wrappers around them, so you can call them from C. It uses Clang's libraries to parse, analyze, and rewrite Objective-C headers into pure C headers, and then generate corresponding source files containing the wrapper implementations. The implementation of this tool is a little hackish at the moment, but it suffices to generate a wrapper around the entire Foundation framework (at least). With this, we don't have to use Objective-C just to use Cocoa anymore. The Mac OS X Quartz driver can go forward now! The QuickTime decoder can use QTKit now instead of the 32-bit only Carbon QuickTime interface, allowing it to work on 64-bit (if and when Wine supports it on Mac). It might even be possible to integrate Win32 screen-savers with Mac OS X using this (the ScreenSaver framework is Objective-C based). I've attached the source so you can play with my newest creation. At the moment, it can only be built on Mac OS X (only one of two platforms, the other being iOS, where a program like this makes sense anyway). Feel free to make changes; the sources are licensed under the same license as Clang itself. We can't incorporate it into Wine directly because it is written in C++ (and maybe because of the license), but we can detect its presence at compile time (in configure) and use it to generate pure C wrappers that Wine can use. Comments welcome. What do you think? Chip deobjectivizer.tar.gz Description: GNU Zip compressed data
Re: Must multimedia players check the message queue and invoke DispatchMessage?
On 4/9/11 12:43 PM, Ove Kaaven wrote: > The function calling GetMessage isn't supposed to do anything beyond > calling DispatchMessage. What about TranslateMessage()? Chip
Re: Google Summer of Code project
On 4/7/11 4:28 PM, Michał Ziętek wrote: > Do you consider putting this project into Google Summer of Code? You can propose whatever you want for GSoC (as long as it's relevant to Wine, or whatever organization you're proposing to). That page is just a list of ideas to get you started. In fact, I proposed something myself you won't find on that list: a graphics driver that uses the native graphics system on Mac OS X. Chip
Re: riched20: Remove the unneeded DEFINE_STDCALL_WRAPPER.
On 4/7/11 3:28 PM, Michael Stefaniuc wrote: > On 04/07/2011 07:04 PM, Dylan Smith wrote: >> On Thu, Apr 7, 2011 at 1:00 PM, Dylan Smith >> wrote: >>> >>> The rest of the richedit code needs to call the ITextHost interface >>> using the thiscall calling convention, so on i386 it calls a thunk in >>> itextHostStdcallVtbl which are defined using the stdcall calling >>> convention, and perform stdcall->thiscall conversion before jumping to >>> the thiscall defined method (i.e. the actual method for user provided >>> ITextHost, and a thunk to reverse the calling convention in Wine). >> >> Sorry, that last part should read (i.e. the actual method for user >> provided ITextHost, OR a thunk to reverse the calling convention for >> calling the internal ITextHostImpl). > Thanks for the explanation. It kinda makes sense but it still feels ugly. I don't know if this will help but... Both Clang and (recent) GCC have direct support for __attribute__((thiscall)) (and I would know about Clang, I added it to the LLVM side). We could potentially take advantage of this and not have to declare thunks like this. Chip
Re: Summer of Code 2011 ideas
On 3/27/11 5:53 PM, Charles Davis wrote: > 1. Quartz Driver. I know you guys rejected this last year, but it looks > like AJ's been doing some work refactoring the driver interface (at > least, the GDI driver interface) lately. I also have some patches to > isolate the rest of Wine from winex11. Since the driver itself is so > huge, I'll probably end up only doing a piece of it (just enough to run > some simple programs like Notepad or Minesweeper). This still depends on > my (as yet, unfinished) Deobjectivizer tool so I don't have to code the > driver in Objective-C (or resort to Carbon, which Apple seems intent on > exorcising from Mac OS X). > 2. D3D10 support. Here's an idea that isn't tied to Mac OS X. In Wine, > D3D10 support is still in the embryonic stage (i.e. lots of stubs, > anything interesting doesn't work quite right). It looks like Henri > wants to wait until he finishes exorcising COM from WineD3D to finish > implementing D3D10 (probably because COM was too much of a burden for > what D3D10 needed from WineD3D, judging from which methods are stubs), > so if you want to wait, that's fine. If I do take this on, my goal will > probably be to get the game "Civilization V" working (at least, > partially) in D3D10 mode, because that's the only D3D10 game I happen to > own! (If it already works, and I don't know if it does because I haven't > gotten around to installing and testing it, then I'll try to make it > work better.) I haven't heard any real objections to these two (the third has been subsumed by someone with a much better proposal), so unless someone speaks up now, I will submit proposals tomorrow. BTW, if I do take up the D3D10 project, I'll consider using WoW's experimental D3D10 engine (as suggested by Jerome Leclanche) to test my D3D10 implementation. Chip
Re: Project: x86 to ARM binary translator
On 4/1/11 6:19 PM, Yale Zhang wrote: > Fellow developers, > > I'm thinking of starting a VM project to allow running x86 Windows apps > on ARM Android. This will obviously involve binary translation. I've > read about QEMU's tiny code generator and think for a usable experience, > the intermediate micro-op representation will have to be abandoned, and > use a more efficient, though less portable x86 to ARM translator. I also > saw some Google SOC project that tried to incorporate LLVM into QEMU, > but with disastrous slow down if done naively. I still think it's worth > to do so, but lots of care will need to be done to only optimize code > that needs it like Sun's HotSpot Java compiler does. > > Questions: > > 1. How useful would this be and how much interest? > >Obviously, this will be a huge project, and I just want to gauge the > interest before I jump in. Microsoft will be releasing Windows for ARM > soon, so there will be no need to worry about >running Office, Matlab, Visual C++, etc on ARM, leaving only legacy > applications and games to benefit from binary translation. I'm mostly > interested in seeing some 3D games run on my >Xoom. > > 2. What's the best design: whole system VM (qemu) or process VM (qemu & > wine)? > > Process VM: > > + easier to incorporate 3D acceleration at API level > + uses less memory > + better performance (e.g. no need for MMU translation when accessing > memory) > + much better integration with host OS > - needs to maintain custom Windows API implementation (Wine) > > Whole system VM: > > + simpler, more unified to implement > + much better support for apps that are dependent on new, proprietary, > obscure Windows libraries, interfaces(moot because Office, Matlab, > etc will soon be available for ARM) > > Given the aims of only running legacy applications and games, it seems a > foregone conclusion that Wine's process VM approach is best. Comments? > > > 3. Will Wine ever incorporate binary translation? > >My proposed design will obviously use Wine's implementation of the > Windows API, which is huge. I'm not sure how disruptive of a change > binary translation will be to Wine. > >If Wine does incorporate binary translation, maybe they can change > the name to Wine Is Now an Emulator > > > If your're interested in this project, please reply. I'm not competent enough to mentor you, but, being a Mac user, I have a story to tell you. It's about a version of Wine that did incorporate binary translation: Darwine. Darwine was separate from mainline Wine; it incorporated QEMU directly and used it to translate x86 to PowerPC code. In a faraway time when Macs used PowerPC CPUs, Darwine allowed x86 Windows apps to run on Mac OS X. Now that Macs aren't built PowerPC chips anymore, Darwine has been abandoned. You might consider using it as a starting point, though. I switched over to the Mac platform (from Windows) in 2007, well after the PPC->x86 transition began, so I never needed Darwine. I did hear however that Darwine had major problems getting good performance (just as you surmised). You might have better luck rolling your own x86->ARM translator after all. That said, I'm also an LLVM guy, so I hear things like people proposing to modify LLVM's JITter to be adaptive (i.e. to heavily optimize heavy-traffic areas only), just as you propose. If that goes through, you might have better luck integrating LLVM into QEMU (again), then basing your project off of Darwine. Chip
Re: [PATCH] kernel32: Populate HKLM\HARDWARE\DEVICEMAP\Scsi on Mac OS.
On 3/30/11 2:53 AM, Alexandre Julliard wrote: > Charles Davis writes: >> How do you propose to do that? The way this is done on Linux, it's >> probably fine to just build up/tear down an entry for each device that >> HAL/udev detects, but DiskArbitration only handles disks (and not other >> types of SCSI devices) on Mac. > > I don't think we care about other types of devices at this point. All right. Do you want me to rip out the old Linux /proc/ide and /proc/scsi parsing code, or do you want to move that over to mountmgr, too? Chip
Re: [PATCH] kernel32: Populate HKLM\HARDWARE\DEVICEMAP\Scsi on Mac OS.
On 3/29/11 4:34 AM, Alexandre Julliard wrote: > Charles Davis writes: > >> From: Charles Davis >> >> --- >> dlls/kernel32/Makefile.in |2 +- >> dlls/kernel32/oldconfig.c | 157 >> +++- >> 2 files changed, 154 insertions(+), 5 deletions(-) > > This code needs to be moved to the mountmgr first. OK. How do you propose to do that? The way this is done on Linux, it's probably fine to just build up/tear down an entry for each device that HAL/udev detects, but DiskArbitration only handles disks (and not other types of SCSI devices) on Mac. Chip
Summer of Code 2011 ideas
Hi, I intend to participate in the Google Summer of Code (again), so I'd like to bounce some ideas off of you guys again. (I don't know why; I'll probably end up doing an extension of last year's project that I did for LLVM. But just in case...) I know that students are supposed to start submitting their proposals tomorrow, but better late than never, I guess. Anyway, here are my ideas (in no particular order): 1. Quartz Driver. I know you guys rejected this last year, but it looks like AJ's been doing some work refactoring the driver interface (at least, the GDI driver interface) lately. I also have some patches to isolate the rest of Wine from winex11. Since the driver itself is so huge, I'll probably end up only doing a piece of it (just enough to run some simple programs like Notepad or Minesweeper). This still depends on my (as yet, unfinished) Deobjectivizer tool so I don't have to code the driver in Objective-C (or resort to Carbon, which Apple seems intent on exorcising from Mac OS X). 2. D3D10 support. Here's an idea that isn't tied to Mac OS X. In Wine, D3D10 support is still in the embryonic stage (i.e. lots of stubs, anything interesting doesn't work quite right). It looks like Henri wants to wait until he finishes exorcising COM from WineD3D to finish implementing D3D10 (probably because COM was too much of a burden for what D3D10 needed from WineD3D, judging from which methods are stubs), so if you want to wait, that's fine. If I do take this on, my goal will probably be to get the game "Civilization V" working (at least, partially) in D3D10 mode, because that's the only D3D10 game I happen to own! (If it already works, and I don't know if it does because I haven't gotten around to installing and testing it, then I'll try to make it work better.) 3. Message-mode pipes. I think we can use the sendmsg(2) and recvmsg(2) syscalls to implement this on top of Unix-domain sockets. Then again, I suspect that this was one of the first things AJ thought of--and he hasn't been able to figure out how to do it yet! I have some experience writing Mac OS X kernel extensions (I wrote the SCSI kexts that Wine on Mac uses), and even a little experience writing Linux modules, so that might help with that. I would like to avoid a kernel module, if possible, though. (It's just one more thing that users have to install to make the system work...) What do you think? Chip
Re: Failing kernel32:change and ntdll:change tests on Mac OS
Sorry I waited so long to get back to you. On 3/10/11 3:27 PM, Ken Thomases wrote: > On Mar 10, 2011, at 4:20 PM, Ken Thomases wrote: > >> I doubt Alexandre would accept reworking wineserver around CFRunLoop, I know. Then again, I've often wondered if doing this might be beneficial. I seem to remember kqueue(2) being broken until Mac OS 10.5. >> but I can think of several alternatives: Unfortunately, each of them has a disadvantage. Quite frankly, I'm not liking our options at this point. >> >> 1) Have the wineserver spin off a secondary thread to run the CFRunLoop and >> then communicate to the main thread via a file descriptor. I think, though, >> that keeping the wineserver single-threaded is important, too. Yeah. That makes me think AJ might not accept this, either. Then again, it's not like this thread will actually be servicing requests from Wine processes. Personally, I like it the best (or rather, hate it the least) of all the options you mentioned. >> >> 2) Do this in Wine's userland, like in a service. But then we'd suffer the overhead of (even more) IPC. It's bad enough that we have to talk to the server, but this way the app has to talk to wineserver to talk to a service, and the service has to talk to wineserver so it can talk back to the app. That's a lot of IPC, and that's something I'd rather avoid if possible. Plus, it seems to me that the inotify/dnotify support would have to be reworked in terms of this; otherwise, we'd have to have ugly #ifdef blocks in ntdll's change functions (in addition to the ones already in the server). Alternatively, we could just have the change functions run the run loop themselves, in a special mode (see CFRunLoopRunInMode()) dedicated to waiting for directory changes. I'm not sure how you or AJ feel about that, though. We'd still have to have #ifdef blocks in ntdll, though, if we do it this way. >> >> 3) Do this in a non-Wine process spun off from the wineserver for the sole >> purpose of bridging the notifications from a CFRunLoop/Mach port-based >> mechanism to a file descriptor. If we do it this way, we may as well just spin off a new thread (suggestion 1). It's cheaper to spawn threads rather than processes. There's an argument to be made for saving Unix handles in the server, but I don't think saving one handle (the write end of a pipe) just for this is worth it. There's also the whole "wineserver should be single-threaded" argument, but I already wrote about that under 1). > > 4) Use kqueue directly, with its vnode filter. It would entail opening every > directory in a hierarchy, which might be deemed prohibitive. We could run out of Unix handles pretty quickly if we do it that way. As I recall, the limit on the number of open FDs a process can have is pretty low by default (only 2560 on my system). Of course, the user could raise this limit (the hard limit is unlimited), but still I don't feel comfortable painstakingly opening tens, hundreds, possibly even thousands of file descriptors at once just to watch for changes to them. Chip
Re: [PATCH] winegcc - do not create .exe.so
On 3/20/11 10:28 PM, Ben Klein wrote: > On 21 March 2011 15:10, Charles Davis wrote: >> On 3/20/11 9:31 PM, Ben Klein wrote: >>> On 21 March 2011 12:26, Charles Davis wrote: >>>> Also, as near as I can tell, this will only work on x86 Linux. It won't >>>> work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is >>>> because the 'start' code invokes execve(2) using the interrupt 80h >>>> interface. Even if other systems use int 80h for their syscall vector >>>> (Mac OS does, at least for Unix syscalls), the syscall numbers usually >>>> aren't the same across different platforms. >>> >>> Does this also mean it will fail to work on amd64/ia64 systems? >> For 32-bit (x86) code running on an x86-64/IA64 system, it will work. >> For 64-bit code, no, it won't work. In fact, x86-64 and IA64 kernels >> keep the old int 80h interface around solely for the benefit of old >> 32-bit programs (like old versions of Wine, before Maarten Lankhorst and >> AJ fixed it) that expect it to be there. >> >> In fact, even if 64-bit code supported the int 80h interface, it still >> wouldn't work, because even across different architectures on Linux, the >> syscall numbers are different. > > Thanks for explaining it. > > Something else I noticed in this patch though; what happens to the > environment variables handled by the loader script? Nothing. He even hard-coded the path to the 'wine' binary (as a series of DWORDs, no less!). Chip
Re: [PATCH] winegcc - do not create .exe.so
On 3/20/11 9:31 PM, Ben Klein wrote: > On 21 March 2011 12:26, Charles Davis wrote: >> Also, as near as I can tell, this will only work on x86 Linux. It won't >> work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is >> because the 'start' code invokes execve(2) using the interrupt 80h >> interface. Even if other systems use int 80h for their syscall vector >> (Mac OS does, at least for Unix syscalls), the syscall numbers usually >> aren't the same across different platforms. > > Does this also mean it will fail to work on amd64/ia64 systems? For 32-bit (x86) code running on an x86-64/IA64 system, it will work. For 64-bit code, no, it won't work. In fact, x86-64 and IA64 kernels keep the old int 80h interface around solely for the benefit of old 32-bit programs (like old versions of Wine, before Maarten Lankhorst and AJ fixed it) that expect it to be there. In fact, even if 64-bit code supported the int 80h interface, it still wouldn't work, because even across different architectures on Linux, the syscall numbers are different. Chip
Re: [PATCH] winegcc - do not create .exe.so
On 3/20/11 6:54 PM, Chris Robinson wrote: > On Sunday, March 20, 2011 4:37:07 PM Vitaliy Margolen wrote: >> On 03/20/2011 05:14 AM, Pali Rohár wrote: >>> Can anybody review my patch? >> >> Not sure what you trying to do exactly. Wine already has wrapper that makes >> all wine binaries executable after they are being installed into system. > > Wine installs wrapper scripts which call wine with the appropriate .exe.so > DSO. The .exe.so file can't be run directly. > > As far as I can tell, the patch makes it so the .exe.so file can be run > directly, by adding a _start section that automatically execs wine with all > the same arguments passed on the command line. As a result, it removes the > .so > extension so you can, for example, just run the 'winecfg.exe' executable > itself, with no 'winecfg' wrapper script needed. It's not enough to have a 'start' symbol. The binary has to be of the right type, too. On Mac OS, for example, the binary has to be of the MH_EXECUTE type (instead of MH_BUNDLE, which it would be right now), or you won't be able to execve(2) it. With ELF, the binary type has to be ET_EXEC (instead of ET_DYN). Also, I don't know if Mac OS, Linux, or any other platform allows you to dlopen(3) something that isn't a DSO (MH_DYLIB and MH_BUNDLE on Mac OS, ET_DYN on ELF platforms). In that case, the right answer might just be to leave this alone. Another solution might be to re-implement the Wine loader logic in the executable itself, but I'm not sure if that's a good idea. Also, as near as I can tell, this will only work on x86 Linux. It won't work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is because the 'start' code invokes execve(2) using the interrupt 80h interface. Even if other systems use int 80h for their syscall vector (Mac OS does, at least for Unix syscalls), the syscall numbers usually aren't the same across different platforms. Chip
Failing kernel32:change and ntdll:change tests on Mac OS
Hi, I just got done looking over the latest batch of test results I sent, and one thing really sticks out and bothers me. The Change Notification tests all fail miserably on my machine (a 2009 Mac Pro with Mac OS X 10.6), because that feature hasn't been implemented on Mac yet. I could implement it for 10.5 up, but the problem is that the "public" API for Change Notifications on Mac (the "FSEvents" API, in CoreServices.framework) expects clients to either use a CFRunLoop or (on 10.6 and up) a GCD dispatch queue. I'm sure this won't sit well with AJ. I did some digging, and it turns out that FSEvents just uses a Mach port (whose name is published in root's Mach bootstrap context as "com.apple.FSEvents") to talk to a daemon, fseventsd, which in turn opens a device file, /dev/fsevents, which is the actual gateway to the kernel. Though it's largely undocumented, we could use this device file to implement Change Notification. The FDs that get returned by this file even support kqueues. But, there are two tiny problems with that: 1) You have to be root to open /dev/fsevents. If we do it this way, we will have to wait until the server is converted to run as root. 2) Because this API isn't officially documented, it's unstable and subject to change. (In fact, judging from the kernel source, it's already changed once. There are several 'old' and 'new' variants of the FSEvents ioctls that the kernel handler supports.) I guess the real question is, which way should we do this? If we do it the first way (using the public and documented but kqueue-unfriendly Carbon API), wineserver has to use a CFRunLoop (or, if we're no longer concerned about Leopard, a GCD dispatch queue) in its main loop, and if we do it the second way (using the undocumented and unstable but kqueue-friendly Unix API), wineserver needs to run as root, and may need to cope with API changes. Based on what I've heard, I'm leaning toward the second way, but I want your guys' input before I go ahead. Thanks. Chip
