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
Charles Davis cdavis@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 not worth the trouble. Most modules need to be relocated anyway. It would have to be done in the kernel.
Alexandre Julliard wrote:
Charles Davis cdavis@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 not worth the trouble. Most modules need to be relocated anyway. It would have to be done in the kernel.
AJ:
kernel32.dll or the OS kernel? It is quite an effort to get patches into the MacOSX kernel, but it CAN BE DONE.
kernel32.dll (or kernel64.dll) is a different matter as the project has control over it.
James McKenzie
On 5/17/10 8:13 PM, James McKenzie wrote:
Alexandre Julliard wrote:
Charles Davis cdavis@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 not worth the trouble. Most modules need to be relocated anyway. It would have to be done in the kernel.
AJ:
kernel32.dll or the OS kernel? It is quite an effort to get patches into the MacOSX kernel, but it CAN BE DONE.
I think he's referring to the system kernel, not the Win32 Kernel API (kernel32.dll).
Personally, I prefer making kexts instead of modifying the kernel itself, but if I absolutely have to, I can change the kernel.
Chip
Charles Davis wrote:
On 5/17/10 8:13 PM, James McKenzie wrote:
Alexandre Julliard wrote:
Charles Davis cdavis@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 not worth the trouble. Most modules need to be relocated anyway. It would have to be done in the kernel.
AJ:
kernel32.dll or the OS kernel? It is quite an effort to get patches into the MacOSX kernel, but it CAN BE DONE.
I think he's referring to the system kernel, not the Win32 Kernel API (kernel32.dll).
Personally, I prefer making kexts instead of modifying the kernel itself, but if I absolutely have to, I can change the kernel.
Is this something that should be investigated by the Open/Free-BSD (I cannot keep which version MacOSX is based upon) community for inclusion into the base kernel?
If it is not, then it should be something under consideration by the Wine project. Hacking the kernel to make one program work is not a 'best practice'.
James McKenzie
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 modified Mach kernel (the way NT uses a "modified microkernel") called "XNU". Many of XNU's BSD parts were forked from FreeBSD (a few parts come from other BSDs).
You can get the source from http://www.opensource.apple.com . It's the 'xnu' project, after selecting a version of Mac OS X.
If it is not, then it should be something under consideration by the Wine project. Hacking the kernel to make one program work is not a 'best practice'.
That might be true, but AJ doesn't seem to be warm to the idea of doing this in Wine.
Chip
Charles Davis wrote:
On 5/17/10 9:10 PM, James McKenzie wrote:
Maybe. Actually, Mac OS X doesn't use a stock FreeBSD kernel. It uses a modified Mach kernel (the way NT uses a "modified microkernel") called "XNU". Many of XNU's BSD parts were forked from FreeBSD (a few parts come from other BSDs).
You can get the source from http://www.opensource.apple.com . It's the 'xnu' project, after selecting a version of Mac OS X.
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?
If it is not, then it should be something under consideration by the Wine project. Hacking the kernel to make one program work is not a 'best practice'.
That might be true, but AJ doesn't seem to be warm to the idea of doing this in Wine.
It appears that it the case. Sometimes sticking to your guns gets you shot (at least around here in Southeastern Arizona.)
However, this is your fix and definitely your call if you want to press AJ about it, or if you want to go to Apple and get the fix into the kernel.
James McKenzie
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 to Darwin in general.
There's a mailing list, 'darwin-kernel@lists.apple.com', dedicated to Darwin kernel development. I would start by submitting patches there.
If it is not, then it should be something under consideration by the Wine project. Hacking the kernel to make one program work is not a 'best practice'.
That might be true, but AJ doesn't seem to be warm to the idea of doing this in Wine.
It appears that it the case. Sometimes sticking to your guns gets you shot (at least around here in Southeastern Arizona.)
Heh.
However, this is your fix and definitely your call if you want to press AJ about it, or if you want to go to Apple and get the fix into the kernel.
The thing is, the support we need already *is* in the kernel. mmap(2) supports unaligned offsets. But there are two wrappers in the System Library:
0000420c T _mmap 0000417f T _mmap$UNIX2003
The second one is the default wrapper. That wrapper rejects unaligned file offsets (to be compliant with UNIX '03). The first one, however, does not reject them. All my patch does is make Wine call the first one instead of the second one when mapping a PE file.
Chip
-
Alexandre Julliard -
Charles Davis -
James McKenzie