Re: Making wine default to the Mac Driver on OS X
On Mon, Mar 4, 2013 at 8:36 PM, Alexandre Julliard julli...@winehq.org wrote: Ken Thomases k...@codeweavers.com writes: If the concern is what you get when you're ssh'd into a remote system, then it's probably possible for the Mac driver to detect when it doesn't have GUI console access and fail. Then, Wine could fall back to X11. If that can be made to work, it would certainly be a nice solution. The current session type can be queried by the command launchctl managername It'll say Aqua for GUI console and either Background or StandardIO for ssh. It seems to be using a private API to fetch this though: http://www.opensource.apple.com/source/launchd/launchd-442.26.2/support/launchctl.c Regards, -- Per Johansson
Re: comctl32/imagelist: use proper color format for merged image lists (try 2)
Daniel Jelinski djelins...@gmail.com writes:
+static void test_merge_colors(void)
+{
+HIMAGELIST himl[5], hmerge;
+int sizes[] = { ILC_COLOR4, ILC_COLOR8, ILC_COLOR16, ILC_COLOR24,
ILC_COLOR32 };
You should also test COLORDDB, and probably the mask behavior too.
--
Alexandre Julliard
julli...@winehq.org
Re: server/advapi32: Report administrator ownership by default for registry objects (try 5).
Erich E. Hoover ehoo...@mymail.mines.edu writes:
+static struct security_descriptor *key_get_sd( struct object *obj )
+{
+struct security_descriptor *sd = default_get_sd( obj );
+const SID *admins_sid = security_builtin_admins_sid;
+int admin_len;
+char *ptr;
+
+if (sd) return sd;
+admin_len = FIELD_OFFSET(SID,
SubAuthority[admins_sid-SubAuthorityCount]);
+sd = mem_alloc( sizeof(struct security_descriptor) + 2*admin_len );
+if (!sd) return sd;
+
+sd-control = 0;
+sd-owner_len = admin_len;
+sd-group_len = admin_len;
+sd-sacl_len = 0;
+sd-dacl_len = 0;
+
+ptr = (char *)(sd + 1);
+memcpy( ptr, security_builtin_admins_sid, sd-owner_len );
+ptr += sd-owner_len;
+memcpy( ptr, security_builtin_admins_sid, sd-group_len );
+ptr += sd-group_len;
+
+free( obj-sd );
+obj-sd = sd;
+return sd;
+}
It shouldn't be necessary to allocate one for every key.
--
Alexandre Julliard
julli...@winehq.org
[PATCH 2/2] winmm: MCI_BREAK_HWND handling now matches Wine's 1999 MCI_DefYieldProc.
Hi, It doesn't make sense to add workarounds for Wine code, it should be fixed instead. That's why I had separated this debatable part into patch 2/2. But what about patch 1/2 not yet committed? That one contains all stuff that's not debatable and is backed up by tests from w2k-w7. 1/2 is stand-alone, despite the /2. I'll not touch MCI_BREAK_HWND, because all of this windows messaging stuff. Somebody else please contribute PeekMessage etc. code. Regards, Jörg Höhle
mmdevapi: Prevent 64 bit overflow within a few days of audio device use. (try 2)
Hi, Michael Stefaniuc wrote: But I see that even the whole functionality can move to a helper. That's not a good idea: While the code currently contains two identical pieces of code, it is actually bogus because the capture part should *not* store current time rather than get *recorded* time. Thus the code looks like there's something that could be refactored, but that would be the wrong refactoring. Regards, Jörg Höhle
Re: comctl32/imagelist: use proper color format for merged image lists (try 2)
Hello,
No surprises in mask behavior - the result is always masked. On the
other hand, merging ILC_COLOR16 with ILC_COLORDDB (which is 32bit)
results in 16bit image:
https://testbot.winehq.org/JobDetails.pl?Key=24624
All other merges (including reverse of the above = ILC_COLORDDB with
ILC_COLOR16) use the greater of the color depths from source
imagelists.
Any idea what might be happening there?
Regards,
Daniel
2013/3/5 Alexandre Julliard julli...@winehq.org:
Daniel Jelinski djelins...@gmail.com writes:
+static void test_merge_colors(void)
+{
+HIMAGELIST himl[5], hmerge;
+int sizes[] = { ILC_COLOR4, ILC_COLOR8, ILC_COLOR16, ILC_COLOR24,
ILC_COLOR32 };
You should also test COLORDDB, and probably the mask behavior too.
--
Alexandre Julliard
julli...@winehq.org
spec file and -arch
Hi, when i look into msvcr100.spec file i find lots of different parameters for the switch (?) -arch . So fare i have seen: arm, i386, win32, win64 and x86_64 . To me it is not clear what is the difference between win64 and x86_64. The same for i386 and win32. What are is the criteria to choose the first or the second? If it makes a difference do i have to distinguish between arm and ... ? Does -i386 and -arch=i386 mean the same? Thank you for enlightening me Stefan
Re: msxml3: Implement IXMLParser Get/Set Factory
On 3/6/2013 09:11, Alistair Leslie-Hughes wrote: Hi, Changelog: msxml3: Implement IXMLParser Get/Set Factory You also need to release factory reference on parser release it seems. Best Regards Alistair Leslie-Hughes
Re: [1/3] Make mac driver the default on OS X
On Mar 5, 2013, at 6:32 PM, Josh DuBois wrote: --- dlls/gdi32/driver.c | 102 +++-- dlls/gdi32/gdi32.spec |1 + dlls/gdi32/gdi_private.h |2 + dlls/user32/driver.c | 27 ++-- include/wine/gdi_driver.h | 11 + 5 files changed, 125 insertions(+), 18 deletions(-) 0001-Track-and-report-multiple-errors-loading-display-drive.txt As I believe you're aware, I think that the Mac driver should not be made the default until OpenGL and clipboard support are in. So, maybe this was just submitted in preparation for that time, but there should probably have been a note to that effect. Also, this patch seems exceedingly complex for a relatively simple problem. Just because it has historically been user32 that reported failure to load the driver doesn't mean it must remain so, at least to my way of thinking. Why not just print out the diagnostics directly in gdi32 as each attempt to load a driver fails? In user32, there can be a secondary, driver-agnostic message about failure to create a window. +case ERROR_DLL_INIT_FAILED: +load_err-err_msg = Make sure you have permission to create \na window or check for errors with Console.app. \n(The Mac driver cannot do remote display: try X11 if you need that.); +break; Make sure you have permission to create a window doesn't mean anything to me. Checking Console.app isn't very useful either. If the user sees this message, then they're already looking at wherever the process's output is going. Running Wine from a shell won't write anything to the console logs. As of Mountain Lion, running it from a GUI app won't either; Apple changed things so that stdout and stderr of GUI apps go to /dev/null rather than console logs. (Only things like NSLog() or asl_log() go to the console log.) Probably it's just best to say that the Mac driver is running in a non-GUI session such as a remote login. -Ken
Re: [3/3] Make mac driver the default on OS X
On Mar 5, 2013, at 6:32 PM, Josh DuBois wrote:
diff --git a/dlls/winemac.drv/macdrv_main.c b/dlls/winemac.drv/macdrv_main.c
index cd1cc0c..1f16694 100644
--- a/dlls/winemac.drv/macdrv_main.c
+++ b/dlls/winemac.drv/macdrv_main.c
@@ -85,7 +85,7 @@ static BOOL process_attach(void)
macdrv_err_on = ERR_ON(macdrv);
if (macdrv_start_cocoa_app(GetTickCount64()))
{
-ERR(Failed to start Cocoa app main loop\n);
+TRACE(Failed to start Cocoa app main loop\n);
return FALSE;
}
I would think that this should still be at least a WARN, although I'm not sure
why it's being demoted from ERR in the first place. (In fact, I should
probably have added a WARN in my patch for refusing to run in non-GUI sessions.)
-Ken
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
On Mon, Mar 04, 2013 at 05:49:46PM -0500, Simo wrote: On 03/04/2013 04:19 PM, J. Bruce Fields wrote: On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote: [possible resend -- sorry] On 02/28/2013 07:25 AM, Pavel Shilovsky wrote: This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic. These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients. According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why one extra flag O_DENYMAND is added. It indicates to underlying layer that an application want to use O_DENY* flags semantic. It allows us not affect native Linux applications (that don't use O_DENYMAND flag) - so, these flags (and the semantic of open syscall that they bring) are used only for those applications that really want it proccessed that way. So, we have four new flags: O_DENYREAD - to prevent other opens with read access, O_DENYWRITE - to prevent other opens with write access, O_DENYDELETE - to prevent delete operations (this flag is not implemented in VFS and NFS part and only suitable for CIFS module), O_DENYMAND - to switch on/off three flags above. O_DENYMAND doesn't deny anything. Would a name like O_RESPECT_DENY be better? Other than that, this seems like a sensible mechanism. I'm a little more worried: these are mandatory locks, and applications that use them are used to the locks being enforced correctly. Are we sure that an application that opens a file O_DENYWRITE won't crash if it sees the file data change while it holds the open? The redirector may simply assume it has full control of that part of the file and not read nor send data until the lock is released too, so you get conflicting views of the file contents between different clients if you let a mandatory lock not be mandatory. In general the idea of making a mandatory lock opt-in makes me nervous. I'd prefer something like a mount option, so that we know that everyone on that one filesystem is playing by the same rules, but we can still mount filesystems like / without the option. +1 But I'll admit I'm definitely not an expert on Windows locking and may be missing something about how these locks are meant to work. Mandatory locks really are mandatory in Windows. That may not be nice to a Unix system but what can you do ? I wonder if we could repurpose the existing -omand mount option? That would be a problem for anyone that wants to allow mandatory fcntl locks without allowing share locks. I doubt anyone sane actually uses mandatory fcntl locks, but still I suppose it would probably be better to play it safe and use a new mount option. --b.
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
On 03/05/2013 01:13 PM, J. Bruce Fields wrote: On Mon, Mar 04, 2013 at 05:49:46PM -0500, Simo wrote: On 03/04/2013 04:19 PM, J. Bruce Fields wrote: On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote: [possible resend -- sorry] On 02/28/2013 07:25 AM, Pavel Shilovsky wrote: This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic. These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients. According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why one extra flag O_DENYMAND is added. It indicates to underlying layer that an application want to use O_DENY* flags semantic. It allows us not affect native Linux applications (that don't use O_DENYMAND flag) - so, these flags (and the semantic of open syscall that they bring) are used only for those applications that really want it proccessed that way. So, we have four new flags: O_DENYREAD - to prevent other opens with read access, O_DENYWRITE - to prevent other opens with write access, O_DENYDELETE - to prevent delete operations (this flag is not implemented in VFS and NFS part and only suitable for CIFS module), O_DENYMAND - to switch on/off three flags above. O_DENYMAND doesn't deny anything. Would a name like O_RESPECT_DENY be better? Other than that, this seems like a sensible mechanism. I'm a little more worried: these are mandatory locks, and applications that use them are used to the locks being enforced correctly. Are we sure that an application that opens a file O_DENYWRITE won't crash if it sees the file data change while it holds the open? The redirector may simply assume it has full control of that part of the file and not read nor send data until the lock is released too, so you get conflicting views of the file contents between different clients if you let a mandatory lock not be mandatory. In general the idea of making a mandatory lock opt-in makes me nervous. I'd prefer something like a mount option, so that we know that everyone on that one filesystem is playing by the same rules, but we can still mount filesystems like / without the option. +1 But I'll admit I'm definitely not an expert on Windows locking and may be missing something about how these locks are meant to work. Mandatory locks really are mandatory in Windows. That may not be nice to a Unix system but what can you do ? I wonder if we could repurpose the existing -omand mount option? That would be a problem for anyone that wants to allow mandatory fcntl locks without allowing share locks. I doubt anyone sane actually uses mandatory fcntl locks, but still I suppose it would probably be better to play it safe and use a new mount option. Maybe we should have a -o win_semantics option :-) /me runs Simo.
