Hi,
My name is Charles Davis, but you all can call me Chip.
I'm new to Wine development, and frankly, I'm kinda scared because I've
heard and read that getting patches into Wine is very difficult. In
fact, every time I got ready to send this first patch, I chickened out
and couldn't do it. So, I
Oops, forgot to reply all.
Charles Davis wrote:
James McKenzie wrote:
Charles Davis wrote:
Hi,
My name is Charles Davis, but you all can call me Chip.
I'm new to Wine development, and frankly, I'm kinda scared because I've
heard and read that getting patches into Wine is very difficult
Damn it, I keep forgetting to reply all.
Charles Davis wrote:
Vitaliy Margolen wrote:
Charles Davis wrote:
Hi,
My name is Charles Davis, but you all can call me Chip.
I'm new to Wine development, and frankly, I'm kinda scared because I've
heard and read that getting patches into Wine
Keith Muir wrote:
Charles Davis wrote:
Damn it, I keep forgetting to reply all.
Charles Davis wrote:
Vitaliy Margolen wrote:
Charles Davis wrote:
Hi,
My name is Charles Davis, but you all can call me Chip.
I'm new to Wine development, and frankly, I'm kinda scared
joerg-cyril.hoe...@t-systems.com wrote:
Chip,
I had hoped that your patch would allow mcicda to work,
cf. bug #20323, alas it is not so. Instead I get to see
ERR(This version of Mac OS X does not support IOCDAudioControl
on Leopard.
I googled slightly and found a message from 2004:
Roderick Colenbrander wrote:
Hi,
I don't know much about the cd-rom stuff on osx but I expect there are
much more issues of which some are more severe than this (and the
solution might fix all the issues). I believe that on osx there is no
such thing as direct cd-rom access (anymore) and
Emmanuel Maillard wrote:
Hi,
For peoples interested with cd-rom support on Mac OS X, i think that you
need to investigated in IOKit,
especially in SCSITaskDeviceInterface and MMCDeviceInterface.
Emmanuel
I know. I have patches for all that. Did I not just write an email back
to Roderick
Hi,
Eventually, I want to implement IOCTL_SCSI_PASS_THOROUGH on Mac OS. The
way I see it, there are two ways to do this:
1. Use the SCSITaskDevice interface. This is a CFPlugIn object provided
by the driver (it's like a COM object). We have to get exclusive access
(this requires all the handles
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
Eventually, I want to implement IOCTL_SCSI_PASS_THOROUGH on Mac OS. The
way I see it, there are two ways to do this:
1. Use the SCSITaskDevice interface. This is a CFPlugIn object provided
by the driver (it's like
Steven Edwards wrote:
On Sat, Oct 17, 2009 at 12:39 PM, Alexandre Julliard
julli...@winehq.org wrote:
1. Use the SCSITaskDevice interface. This is a CFPlugIn object provided
by the driver (it's like a COM object). We have to get exclusive access
(this requires all the handles to all device
James McKenzie wrote:
Charles Davis wrote:
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
Eventually, I want to implement IOCTL_SCSI_PASS_THOROUGH on Mac OS. The
way I see it, there are two ways to do this:
1. Use the SCSITaskDevice interface
Hi,
This patch will implement CDROM_GetInterfaceInfo() (and its associated
IOCTL) on Mac OS X. The problem is that it's big, it's complicated, and
it uses I/O Kit. From what I've seen, Alexandre doesn't exactly like I/O
Kit that much. Anyway, I want someone to review the patch.
No, I could not
Hi,
Here's a new version of my patch that's slightly less complicated. I
didn't get a response last time, so I'm sending it again. Please,
someone review my patch. I won't send it to wine-patches until I know I
have this right (yes, I am a bit of a perfectionist).
To reiterate what I said about
Charles Davis wrote:
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
Here's a new version of my patch that's slightly less complicated. I
didn't get a response last time, so I'm sending it again. Please,
someone review my patch. I won't send it to wine-patches until I
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
Charles Davis wrote:
Alexandre Julliard wrote:
That sort of thing should most likely be integrated with the
diskarbitration stuff in mountmgr.
Really? I guess I could do it that way. But then how
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
Now I just need to figure out how to do that. I read the headers and
source, and figured out a QUERY_UNIX_DRIVE won't work because it needs a
drive letter, and NTDLL isn't supposed to know about drive letters.
Maybe we
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
Oh, I see. You mean I should open a handle to mountmgr with
NtOpenFile(). That's what I thought. Now I just need to figure out the
right IOCTL. Maybe I need to make one up. And I still don't know how to
specify
Charles Davis wrote:
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
Oh, I see. You mean I should open a handle to mountmgr with
NtOpenFile(). That's what I thought. Now I just need to figure out the
right IOCTL. Maybe I need to make one up. And I still don't know how
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
Or, maybe not. I could be totally wrong about that. Maybe what you
really want is for me to get an FD from mountmgr so I can talk to it at
will. I don't know.
We can even add the FD to mountmgr's run loop (via
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
Or, maybe not. I could be totally wrong about that. Maybe what you
really want is for me to get an FD from mountmgr so I can talk
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
OK, so let me see if I have all this straight: you want me to implement
some wine-specific IOCTLs in mountmgr that return the SCSI address and
anything else I can think of tha belongs in mountmgr. You also say
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
OK, thanks. Now I've got this straight. I should do something like
dlls/mountmgr.sys/device.c, where I'd have an NT device like
\Device\CdRom0 (or some such), whose FD I'd pass to the server so that
when NTDLL opens
Charles Davis wrote:
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
OK, thanks. Now I've got this straight. I should do something like
dlls/mountmgr.sys/device.c, where I'd have an NT device like
\Device\CdRom0 (or some such), whose FD I'd pass to the server so
Charles Davis wrote:
Charles Davis wrote:
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
OK, thanks. Now I've got this straight. I should do something like
dlls/mountmgr.sys/device.c, where I'd have an NT device like
\Device\CdRom0 (or some such), whose FD I'd pass
I've fixed most of the issues with my patch set (warnings, crashes,
dangling FDs... yeah, I'll admit that last set of mine was a piece of
crap; that'll teach me to send before testing), but I have one concern.
After my patch series is applied, NtOpenFile() and NtCreateFile(), when
handed a drive,
Charles Davis wrote:
Hi,
This patch series moves drive handling over to mountmgr. Mountmgr will
now associate UNIX device files directly to its created devices instead
of having ntdll handle converting something like \??\D: to
$WINEPREFIX/dosdevices/d::. This way, we can implement storage I
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
I thought I fixed all the issues. What's wrong with my patches now?
Many things, it's a lot more complicated than that. For instance you
can't just kill the fstab support, this needs to be preserved somehow,
probably
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
I thought I fixed all the issues. What's wrong with my patches now?
Many things, it's a lot more complicated than that. For instance you
can't just kill the fstab support, this needs to be preserved somehow,
probably
Charles Davis wrote:
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
I thought I fixed all the issues. What's wrong with my patches now?
Many things, it's a lot more complicated than that. For instance you
can't just kill the fstab support, this needs to be preserved
Vitaliy Margolen wrote:
Charles Davis wrote:
Also, add stub handlers in mountmgr.
This patch fixes an issue with the previous one where wine would hang if
ntoskrnl got a STATUS_BUFFER_OVERFLOW back from thes server.
---
+int suspend_thread( struct thread *thread );
+int resume_thread
in advance.
Chip
From db073155c888747b9259cb8fe0d5ff2a59ee5666 Mon Sep 17 00:00:00 2001
From: Charles Davis cda...@mymail.mines.edu
Date: Tue, 17 Nov 2009 11:10:50 -0700
Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile.
To: wine-patches wine-patc...@winehq.org
Reply-To: wine-devel wine
...@gmail.com wrote:
This passes on my Windows XP vm and on Wine here.
On Tue, Nov 17, 2009 at 12:44 PM, Charles Davis cda...@mymail.mines.edu
wrote:
Hi,
I have a test that I wrote from scratch for bug 4543. It tests the
operation of BitBlt to a metafile, first from the screen then pure
on Windows, too.
Chip
From 2d5aa7c607496c1b05a7a08adfee09db446754cb Mon Sep 17 00:00:00 2001
From: Charles Davis cda...@mymail.mines.edu
Date: Tue, 17 Nov 2009 11:10:50 -0700
Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile.
To: wine-patches wine-patc...@winehq.org
Reply-To: wine-devel wine-devel
Vincent Povirk wrote:
Now on windows (with s/if(0)/if(1)/) I get lots of:
metafile.c:740: Test failed: unexpected EMF bits: got 01, expected 0xff
metafile.c:740: Test failed: unexpected EMF bits: got 00, expected 0xff
metafile.c:740: Test failed: unexpected EMF bits: got 00, expected
platforms before I send this to wine-patches.
Chip
From 2d5aa7c607496c1b05a7a08adfee09db446754cb Mon Sep 17 00:00:00 2001
From: Charles Davis cda...@mymail.mines.edu
Date: Tue, 17 Nov 2009 11:10:50 -0700
Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile.
To: wine-patches wine-patc
, but not on Wine. (There
should be a function in wine/test.h for doing this.) Patch attached.
On Tue, Nov 17, 2009 at 6:09 PM, Charles Davis cda...@mymail.mines.edu
wrote:
All right, this should be the last one. The tests pass on Wine, and
should pass on Windows if you un-if(0) the call to BitBlt
Dmitry Timoshkov wrote:
Charles Davis cda...@mymail.mines.edu wrote:
I've attached the patch so you can build a gdi32_test.exe that contains
my tests.
Why don't you use the same way of comparing EMFs as other tests do,
compare_emf_bits()/dump_emf_bits()/dump_emf_records()?
Because I
Charles Davis wrote:
Dmitry Timoshkov wrote:
Charles Davis cda...@mymail.mines.edu wrote:
I've attached the patch so you can build a gdi32_test.exe that contains
my tests.
Why don't you use the same way of comparing EMFs as other tests do,
compare_emf_bits()/dump_emf_bits()/dump_emf_records
Charles Davis wrote:
Charles Davis wrote:
Dmitry Timoshkov wrote:
Charles Davis cda...@mymail.mines.edu wrote:
I've attached the patch so you can build a gdi32_test.exe that contains
my tests.
Why don't you use the same way of comparing EMFs as other tests do,
compare_emf_bits
people to run this test on Windows to make sure it's an accurate
representation of Windows' behavior. The test currently succeeds on Wine.
Thanks in advance.
Chip
From 574bb4f7b2b90a209b1693b7f8048a2eb271ada8 Mon Sep 17 00:00:00 2001
From: Charles Davis cda...@mymail.mines.edu
Date: Tue, 17 Nov 2009
Ricardo Filipe wrote:
2009/11/19 Charles Davis cda...@mymail.mines.edu:
Hi,
This is a new version of my test for bug 4543. This time, I followed
Dmitry's suggestion of using the existing functions for comparing the
contents of EMFs. I can't build tests for Windows both due to bug 20763
Paul Vriens wrote:
On 11/19/2009 11:17 PM, Charles Davis wrote:
Hi,
This is a new version of my test for bug 4543. This time, I followed
Dmitry's suggestion of using the existing functions for comparing the
contents of EMFs. I can't build tests for Windows both due to bug 20763
and due
Paul Vriens wrote:
On 11/19/2009 11:17 PM, Charles Davis wrote:
Hi,
This is a new version of my test for bug 4543. This time, I followed
Dmitry's suggestion of using the existing functions for comparing the
contents of EMFs. I can't build tests for Windows both due to bug 20763
and due
Paul Chitescu wrote:
On Monday 16 November 2009 04:11:25 pm Paul Chitescu wrote:
Changelog:
Add .cvsignore entries for .fake files.
What's wrong with this? Applies cleanly to my pristine wine-CVS, tried with
patch taken from wine-patches bounce.
Whoever rejected with fails to apply
Dmitry Timoshkov wrote:
Charles Davis cda...@mymail.mines.edu wrote:
+if(1 || compare_emf_bits(hMetafile, EMF_BITBLT, sizeof(EMF_BITBLT),
+emf_BitBlt, FALSE) != 0)
+{
+dump_emf_bits(hMetafile, emf_BitBlt);
+dump_emf_records(hMetafile, emf_BitBlt
Dmitry Timoshkov wrote:
Charles Davis cda...@mymail.mines.edu wrote:
You forgot to remove if (1).
It goes away in patch #3. I thought I already had this discussion with
Paul.
There's a reason it's there. EMF_BITBLT contains two BitBlt() records,
but the EMF we're comparing it to only has
Austin English wrote:
On Sat, Nov 21, 2009 at 11:15 PM, Charles Davis cda...@mymail.mines.edu
wrote:
Dmitry Timoshkov wrote:
Charles Davis cda...@mymail.mines.edu wrote:
You forgot to remove if (1).
It goes away in patch #3. I thought I already had this discussion with
Paul.
There's
Ken Thomases wrote:
The call to setenv() has 0 (false) as its third parameter, so that LANG is
not overwritten.
Then why does Wine not repsect the LANG setting on Mac OS X? I've seen
it on wine-users. Wherever the problem lies, it lies elsewhere.
(Yeah, I forgot what that third parameter to
I just realized something. The reason Wine doesn't respect LANG is that
it overrides the LC_MESSAGES setting if it is set to the default. It
will be set to the default if there is no LC_MESSAGES in the
environment. So we don't want to override LC_MESSAGES if there's a LANG
variable in the
This really belongs on the wine-users mailing list.
Chip
Maarten Lankhorst wrote:
Paul Chitescu schreef:
Changelog:
kernel32.dll: Reduce Registry access to KEY_READ or
MAXIMUM_ALLOWED wherever possible
In many places reading the Registry is enough to work even when write
access is denied.
Your patches cannot be applied with -Np1,
Alexandre Julliard wrote:
Maarten Lankhorst m.b.lankho...@gmail.com writes:
Hello Alexandre,
Alexandre Julliard schreef:
Openal missing at compile time or at runtime should be handled the same
way, i.e. by reporting no sound devices. It doesn't make sense to have
two different failure
You don't get added to AUTHORS until you've hacked on Wine enough. I
learned that the hard way when I tried to put my name at the top of an
already-existing file.
Chip
James McKenzie wrote:
All:
I'm asking a question again, don't 'shoot' me, but I've noticed the use
of the trace() function in tests and I would like to use this to
troubleshoot what is incorrect in the EM_FORMATRANGE patch as it is not
passing on MacOSX builds. The test appears to pass on
James McKenzie wrote:
Charles Davis wrote:
James McKenzie wrote:
All:
I'm asking a question again, don't 'shoot' me, but I've noticed the use
of the trace() function in tests and I would like to use this to
troubleshoot what is incorrect in the EM_FORMATRANGE patch as it is not
passing
Ken Thomases wrote:
On Dec 3, 2009, at 11:27 AM, Ken Thomases wrote:
I propose the following (in pseudocode):
mac_formats_locale = CFLocaleGetIdentifier( CFLocaleCopyCurrent() );
mac_language = CFArrayGetValueAtIndex(
CFBundleCopyLocalizationsForPreferences(
Austin English wrote:
On Wed, Dec 16, 2009 at 12:28 PM, Amine Khaldi amine4...@gmail.com wrote:
WBR,
Amine Khaldi.
Out of curiosity, what tool are you using to find these bugs?
I think he's using Clang. I've seen him on the LLVM bugzilla. He's
waiting for someone (e.g. me) to fix the bugs
srrose wrote:
What does this mean? Iim using a USB 2.0 Flash Drive and a LAUNCHU3.EXE
file says it is linked to a missing export. It then says
KERNEL32.DLL:GetVolumeMountPointW.
Can you help me? Thank you!!
Yes... but you're on the wrong list. User questions need to go to
wine-users. And
Christian Costa wrote:
Hi,
make crosstest gives the following output :
../../../tools/winegcc/winegcc -b i586-mingw32msvc
-B../../../tools/winebuild --sysroot=../../.. --lib-suffix=.cross.a
d3drm.cross.o vector.cross.o testlist.cross.o -o d3drm_crosstest.exe
-lkernel32
Dan Kegel wrote:
This message is being sent in gmail in Chromium running on Wine
with options --no-sandbox --use-nss-for-ssl.
(--use-nss-for-ssl turns on a new alternate https stack that works
in wine.)
This copy of Chromium was built in Wine, too. It took 1 hour
55 minutes to compile
Susan Cragin wrote:
./configure --enable-win64 make distclean
./configure --enable-win64 make depend make
Huh? Are you actually trying to build the 64-bit version of Wine? Why
would you want to do that? Especially when 64-bit Wine isn't mature yet.
Did you try it without --enable-win64?
C.W. Betts wrote:
Is is just because of the Objective-C code? Would it be safe to make C
functions that would call Objective-C? Such as:
cheader.h:
typedef struct struct1 struct1;
cfuncCreate(struct1 *s);
cfunc1();
cfunc2();
cfuncDestroy (struct1 *s);
cfile.m:
@interface WHQFunc
{
Jui-Hao Chiang wrote:
Hi, all:
I am currently starting a project which tries to run a window
application on one (source) machine, and display on another
(destination) machine. Of course, the VNC or X11 forwarding technique
can achieve the same goal, but I am trying to reduce the bandwidth
Charles Davis wrote:
I added this to clang yesterday. Now clang will warn every time it
encounters the force_align_arg_pointer attribute applied to a function
pointer. This isn't a problem on Linux, but on Mac OS X those warnings
are going to clutter the output, since we use it so liberally
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
An incomplete list of projects that use force_align_arg_pointer:
- liboil
- ffmpeg
- x264
- Gallium3D
- KDE
Just do a Google search for 'force_align_arg_pointer' and you'll see a
whole bunch of pages about
Erich Hoover wrote:
Real Name:
Erich Hoover
Description:
Patch 2 added support for the all processors flag, so this is
no-longer a todo. This version is against the revised patch 1, please
note that patch 2 is unchanged.
ChangeLog:
kernel32/tests: Test for 'all processors' now
Disregard this patch, it breaks ntoskrnl. New patch forthcoming.
Chip
James McKenzie wrote:
Interestingly enough, I have run into the 'Unable to compile' problem
building the latest git on MacOSX. Maybe there is corruption in my git
pull, but this started yesterday
It appears that configure never fully finishes and config.status loops.
I don't have that
Justin Chevrier wrote:
---
dlls/gdiplus/tests/graphics.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
You're still not getting it!
Remember, when each patch is applied, all the tests must pass. That's
the rule. If the second patch is applied without this
On 3/11/10 7:56 PM, Ben Klein wrote:
Is there other Mac-specific code in Wine?
Yes there is.
how is
it handled?
With #ifdefs. Though it's not incompatible with defining our own ACM
filter specifically for CoreAudio. In fact, all the modules in Wine are
always built; they just get stubbed if the
On 3/13/10 8:23 PM, James McKenzie wrote:
Stefan Dösinger wrote:
Am 08.03.2010 um 13:23 schrieb Roderick Colenbrander:
Hi,
Multiple times a day you encounter people who can't get 3D working in
Wine. I'm getting so sick of these questions, that I decided to start
a new page on the Wiki.
On 3/19/10 3:02 PM, Eric Pouech wrote:
(and maps the definition to what MSDN states as field names)
A+
---
dlls/ntdll/signal_x86_64.c | 144
++--
1 files changed, 58 insertions(+), 86 deletions(-)
You forgot unwind.h.
Chip
Hi,
I intend to participate in the Google Summer of Code this year, and I
have several ideas for Wine that I'd like to bounce off you guys to see
what you think. Note that all my proposals are Mac OS-based (I run Mac
OS X), so many of you will never see the results of what I'm working on.
Here
On 3/22/10 12:22 PM, Roderick Colenbrander wrote:
Previous attempts at a Quartz driver roughly the tried to create a new
driver in a design similar to winex11. If we start a new driver, the
current driver design and winex11 need to be cleaned up. This requires
a dib engine :( Further I expect
On 3/23/10 10:49 PM, Dan Kegel wrote:
Bisecting: 0 revisions left to test after this (roughly 0 steps)
Uhh... You're not done yet.
I would've thought you knew that! Apparently not.
Chip
After configuring, you cd to dlls/user32 and do a make in that
directory, like this:
./configure
make -C dlls/user32
The 'C' parameter tells make to change to that directory before making.
But seriously, why are you trying to run the Win32 version VisualBoy
Advance in Wine anyway? You do
On 4/14/10 10:36 AM, Reece Dunn wrote:
On 14 April 2010 16:19, Matijn Woudt tijn...@gmail.com wrote:
I have thought about using LLVM, but I don't like it because of:
1) Having another wine dependency (~40MB for me on ubuntu)
2) Code generated by LLVM will most likely not generated exactly the
On 4/16/10 2:51 PM, André Hentschel wrote:
---
tools/winegcc/winegcc.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/tools/winegcc/winegcc.c b/tools/winegcc/winegcc.c
index 7023ff4..f780a69 100644
--- a/tools/winegcc/winegcc.c
+++
While building Wine (latest git) on Mac OS X, I noticed this:
/usr/bin/nm: object: amstream_test.MDsdpi.o malformed object (LC_SEGMENT
command 0 filesize field greater than vmsize field)
Undefined symbols:
_GetDesktopWindow, referenced from:
_func_amstream in amstream.o
_TlsGetValue,
On 4/20/10 1:26 PM, eric lanz wrote:
I've seen this error using the os 4.0 beta 1 sdk, using the GM 3.2 sdk I
don't get this error -- so the last couple weeks I've been switching
sdk's back and forth to get around the problem. I'm downloading os 4.0
beta 2 right now to see if apple fixed it.
Hi,
I'm getting ready to implement the Quartz Driver. For those of you who
don't know, this is a special graphics driver that only works on Mac OS
X, and uses its native Core Graphics (aka, Quartz) system to draw.
But before I can do this, there are two things that need to be done:
1. Wine
On 4/23/10 12:47 AM, Hans Leidekker wrote:
We should investigate if the native server can be used by Photoshop.
Then we could write a stub Bonjour service so that Photoshop will not
attempt to install its own version.
One question about making a Windows service: would the programs still
be
On 4/27/10 8:54 PM, C.W. Betts wrote:
Excuse me, but why is this needed again? What IOCTL is missing in Mac OS X's
native implementation?
Do I have to explain everything?!
All right. Here goes.
Way back in October of last year, I started a discussion on this list
about SCSI on Mac OS X:
On 4/28/10 2:14 PM, Stefan Dösinger wrote:
Am 28.04.2010 um 17:35 schrieb Charles Davis:
On 4/28/10 4:03 AM, Stefan Dösinger wrote:
Am 27.04.2010 um 22:10 schrieb Charles Davis:
tar jxf ExtMediaBSDClient.tar.bz2
cd ExtMediaBSDClient
Do you have the sourcecode somewhere
On 4/28/10 9:35 AM, Charles Davis wrote:
I don't have a public repository yet. My plan is to create a SourceForge
project for this (like AJ suggested).
And here it is:
http://sourceforge.net/projects/xnu-extras/
Chip
On 4/28/10 5:02 PM, Ken Thomases wrote:
Hi Charles,
Are the DKIOCPREVENT and DKIOCALLOW ioctls necessary?
They were the reason I first wrote the driver. I added DKIOCSCSICOMMAND
later.
DiskArbitration already has a facility for clients to refuse
mount/unmount/eject requests.
On 4/28/10 5:48 PM, Ken Thomases wrote:
On Apr 28, 2010, at 6:18 PM, Charles Davis wrote:
Besides, to use it, we'd have to call DADiskMount() directly instead of
going through diskutil.
Huh? Who goes through diskutil?
NTDLL, when it gets a FSCTL_DISMOUNT_VOLUME.
Who would have to call
On 4/28/10 11:08 PM, Ken Thomases wrote:
On Apr 28, 2010, at 8:28 PM, Charles Davis wrote:
On 4/28/10 5:48 PM, Ken Thomases wrote:
On Apr 28, 2010, at 6:18 PM, Charles Davis wrote:
Besides, to use it, we'd have to call DADiskMount() directly instead of
going through diskutil.
Huh? Who
On 5/4/10 10:17 AM, Johann Myrkraverk Oskarsson wrote:
Hi all,
In the Solaris/BSD implementation of reserve_area() in libs/wine/mmap.c there
is
for (i = 0; i size; i += pagesize)
if (mincore( (caddr_t)addr + i, pagesize, vec ) != -1) break;
vec is never used again
On 5/4/10 12:06 AM, Joakim Tjernlund wrote:
Here are two versions
Generally, it's a bad idea to put two patches in one mail. You should
instead have two separate emails, one for each patch.
Chip
On 5/6/10 1:57 AM, wy...@volny.cz wrote:
BTW: why it takes so long (cca 6 hours) a post to appear, when i send
mail to wine-devel? Some kind of mail graylist?
If you're not subscribed to wine-devel, your messages are subject to
moderation.
Chip
On 5/7/10 11:10 PM, Henry Blum wrote:
-if (status != STATUS_SUCCESS)
+if (status != STATUS_SUCCESS || (access PROCESS_VM_WRITE))
According to this, opening a process and specifying the PROCESS_VM_WRITE
access right causes OpenProcess() to fail.
Why do you need this? And what about
This is the wrong place to ask. Here we talk about Wine *development*.
You should really be asking this on wine-users.
Chip
On 5/12/10 5:37 PM, Ken Thomases wrote:
What problems does this cause?
It makes Wine use more memory than it needs to.
http://wiki.winehq.org/UnalignedMmap
Can't we achieve that just by avoiding the mapping of the mmap identifier
to the _mmap$UNIX2003 symbol?
We could for 32-bit, but not
On 5/12/10 6:10 PM, Ken Thomases wrote:
On May 12, 2010, at 6:53 PM, Charles Davis wrote:
On 5/12/10 5:37 PM, Ken Thomases wrote:
What problems does this cause?
It makes Wine use more memory than it needs to.
http://wiki.winehq.org/UnalignedMmap
Can't we achieve that just by avoiding
(Charles Davis
made some C wrapper I think). The most problematic thing is that it
really need is a DIB engine. The Cocoa graphics APIs are similar to
Cairo / XRender / Direct2D and other modern APIs. These APIs are great
for vector drawing, alpha blending and other fancy operations
What's wrong with my patch now? It's a really simple fix; in fact, this
is as about as simple as it gets. How does this break libwine
compatibility?
Chip
On 5/17/10 8:13 PM, James McKenzie wrote:
Alexandre Julliard wrote:
Charles Davis cda...@mymail.mines.edu writes:
What's wrong with my patch now? It's a really simple fix; in fact, this
is as about as simple as it gets. How does this break libwine
compatibility?
Like I said, it's
On 5/17/10 9:10 PM, James McKenzie wrote:
Is this something that should be investigated by the Open/Free-BSD (I
cannot keep which version MacOSX is based upon)
It's FreeBSD.
community for inclusion
into the base kernel?
Maybe. Actually, Mac OS X doesn't use a stock FreeBSD kernel. It uses a
On 5/17/10 9:32 PM, James McKenzie wrote:
Next stupid question: How does the patch get back into the XNU kernel
code? Is there a project for it, or do we dump it on Apple's front door
hoping that they will integrate it?
To be honest, I really have no idea exactly how outsiders can contribute
1 - 100 of 243 matches
Mail list logo
