Clang Static analysis
I have been doing a Clang static analysis of Wine on OS X using the one provided at http://clang-analyzer.llvm.org and storing the results on my PogoPlug drive. If someone wants to see the results, please tell me and I'll set up your e-mail. You will need a free PogoPlug account to view them. While the contents are zipped, they expand to about 1.2 GB. They are displayed as basic HTML pages, so you don't need anything special other than a web browser to see the results. Or you could click on this link for the analysis of 1.7.4: http://ppl.ug/ND-7PZ3cSzM/
Re: Wrong status of gdi32
Some of those are probably Wine-specific, and/or are forwarded from other DLLs. On Oct 8, 2013, at 8:35 AM, Akira Nakagawa matyapir...@gmail.com wrote: I found this page shows that gdi32 dll has more than 800 functions,but the spec file has only 500 .
Re: [PATCH 4/5] winemac: Implement rudimentary support for system tray icons as Mac status items.
On Mar 18, 2013, at 3:22 PM, Ken Thomases k...@codeweavers.com wrote: On Mar 18, 2013, at 4:04 PM, Charles Davis wrote: 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 k...@codeweavers.com 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? [...] 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... You answered your own question. ;) At this point, though, I'm wondering if it wouldn't just be easier to have Explorer draw the balloons itself à la Windows XP. Probably. I also considered using an NSPopover anchored to the status item. Again, that's 10.7+ functionality. We could implement it and do compile- and runtime checks to make sure that the functions aren't called in unsupported OS X versions. However, this would probably add fragmentation, and I doubt Alexandre would be happy with this.
Re: [PATCH 4/5] winemac: Implement rudimentary support for system tray icons as Mac status items.
On Mar 17, 2013, at 9:40 PM, Ken Thomases k...@codeweavers.com wrote: Doesn't support right-clicks, mouse moves, or notification balloons. Notification balloons can probably be done using either Notification Center or Growl, but either due to an out-of-date version of Growl in Twitter or a bug in Growl itself, clicking on the Growl notification doesn't bring Twitter to the front for me. --- dlls/winemac.drv/Makefile.in |2 + dlls/winemac.drv/cocoa_status_item.m | 175 + dlls/winemac.drv/event.c |5 + dlls/winemac.drv/image.c |2 +- dlls/winemac.drv/macdrv.h|3 + dlls/winemac.drv/macdrv_cocoa.h | 13 ++ dlls/winemac.drv/systray.c | 358 ++ dlls/winemac.drv/winemac.drv.spec|3 + 8 files changed, 560 insertions(+), 1 deletions(-) create mode 100644 dlls/winemac.drv/cocoa_status_item.m create mode 100644 dlls/winemac.drv/systray.c 0004-winemac-Implement-rudimentary-support-for-system-tra.patch
Re: [0/10] Launcher app bundles on OS X
A quick glance at the source revealed that you removed static from some functions. Why? If a function isn't being called outside a source file, it's better to have it be static. This includes functions referenced in structs (but not the structs themselves). A more seasoned developer is welcome to correct me if I'm wrong. On Mar 17, 2013, at 11:18 AM, Per Johansson p...@morth.org wrote: I'm resending this now after testing it with the Mac driver. They work well together, the launcher bundle will first briefly appear in the dock, then exit, and the mac driver icon appears. It's split it up into parts for easier review. I've also tried to make sure that even if e.g. part 6 fails review, part 1 - 5 can still be applied. File type associations are not included because I plan to move that code into the mac driver but haven't gotten around to it yet. Regards, -- Per Johansson
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 k...@codeweavers.com wrote: On Mar 18, 2013, at 3: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 k...@codeweavers.com 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* I can see that not being an issue on CrossOver, but yes, I doubt that the average person compiling Wine on their Macs has a proper certificate to sign it. As for implementing Growl, a configure check can be done, and a warning shown if a) they are compiling the Mac driver and b) they do not have the Growl development framework installed. This would, however, probably require some work to maintain the Growl framework's presence so that, in example, Wine compiled by MacPorts can be moved to another computer that does not have the Growl framework installed in either /Library/Frameworks or ~/Library/Frameworks. I have done some work with the OS X linker in my project PlayerPRO to get a command-line app to access the framework that is in the same directory of the program, but other than that my linker skills aren't that great.
Re: [PATCH 1/7] winemac: Implement OpenGL support.
It looks like if GL_ARB_shader_objects is defined, then the OS X GLhandleARB isn't typedef'd. On Mar 6, 2013, at 1:16 PM, Ken Thomases k...@codeweavers.com wrote: On Mar 6, 2013, at 1:58 PM, C.W. Betts wrote: It seems like there's conflicting types for GLhandleARB, one defined by Wine, the other by OS X, on Mountain Lion. I assume that the #define __gl_h_ is a try to work around the issue, but OS X's gltypes.h still gets included. Ugh. Thanks for letting me know. I'll have to investigate. I'm not well set up to build against later SDKs at the moment, but I'll see what I can do. Of course, if you can figure out a solution, that would be great. -Ken
Re: [PATCH 1/7] winemac: Implement OpenGL support.
It seems like there's conflicting types for GLhandleARB, one defined by Wine, the other by OS X, on Mountain Lion. I assume that the #define __gl_h_ is a try to work around the issue, but OS X's gltypes.h still gets included. On Mar 6, 2013, at 3:59 AM, Ken Thomases k...@codeweavers.com wrote: --- dlls/winemac.drv/Makefile.in|4 +- dlls/winemac.drv/cocoa_opengl.h | 32 + dlls/winemac.drv/cocoa_opengl.m | 154 dlls/winemac.drv/cocoa_window.m | 187 dlls/winemac.drv/gdi.c |2 +- dlls/winemac.drv/macdrv.h | 10 + dlls/winemac.drv/macdrv_cocoa.h | 15 + dlls/winemac.drv/opengl.c | 1912 +++ dlls/winemac.drv/window.c | 11 +- 9 files changed, 2322 insertions(+), 5 deletions(-) create mode 100644 dlls/winemac.drv/cocoa_opengl.h create mode 100644 dlls/winemac.drv/cocoa_opengl.m create mode 100644 dlls/winemac.drv/opengl.c 0001-winemac-Implement-OpenGL-support.patch
Clang warnings on OS X ML
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 Another worrying warning is that __force_align_arg_pointer__ being an unknown attribute. There's also a lot of enum conversion warnings. There was also a linker warning about register usage, but I can't seem to find it again. I could upload the whole log, but it is fairly large: 6.4 MB.
Re: macdrv: implement getting and setting the screen saver state, version 2
On Jan 20, 2013, at 11:06 PM, Ken Thomases k...@codeweavers.com wrote: Hi, On Jan 20, 2013, at 2:00 PM, C.W. Betts wrote: This version implements changes and advice from Ken Thomases, including using kIOPMAssertionTypePreventUserIdleDisplaySleep on Lion and later. Also, some comments were added. +//Get pre-Lion no display sleep counts C++-style comments (//) are not allowed in Wine C code. They aren't portable. Oops, forgot about that. Fixed. +CFNumberRef count = CFDictionaryGetValue(assertionStates, kIOPMAssertionTypeNoDisplaySleep); +CFNumberRef count2 = NULL; +long longCount = 0; +long longCount2 = 0; +CFNumberGetValue(count, kCFNumberLongType, longCount); +//If available, get Lion and later no display sleep counts +count2 = CFDictionaryGetValue(assertionStates, kIOPMAssertionTypePreventUserIdleDisplaySleep); +if (count2) +CFNumberGetValue(count2, kCFNumberLongType, longCount2); The issue discussed for the previous patch is still present. For example, the following code would be internally consistent and also safe: CFNumberRef count = CFDictionaryGetValue(assertionStates, kIOPMAssertionTypeNoDisplaySleep); CFNumberRef count2 = CFDictionaryGetValue(assertionStates, kIOPMAssertionTypePreventUserIdleDisplaySleep); long longCount = 0; long longCount2 = 0; if (count) CFNumberGetValue(count, kCFNumberLongType, longCount); if (count2) CFNumberGetValue(count2, kCFNumberLongType, longCount2); (Note that this reorganization also eliminates a dead store. You were initializing count2 and then unconditionally assigning it, making the initialization redundant. Such unnecessary initializations also defeat potentially valuable compiler warnings.) Fixed +if (longCount || longCount2 ) There's an extraneous space before the closing parenthesis. Fixed +//Release power assertion +IOReturn success = IOPMAssertionRelease(powerAssertion); The comment is useless. It tells us nothing that the code doesn't. Please don't do that. In fact, most of the comments you added are like this. Done +//Are we running Lion or later? +if (kCFCoreFoundationVersionNumber = kCFCoreFoundationVersionNumber10_7) +//If so, use Lion's name +assertName = kIOPMAssertionTypePreventUserIdleDisplaySleep; +else +//If not, use old name +assertName = kIOPMAssertionTypeNoDisplaySleep; I'm not sure it's correct that these are two different names for roughly the same thing. I think the two assertion types do slightly different things. NoDisplaySleep seeks to prevent display sleep for any (non-forced) reason. PreventUserIdleDisplaySleep only seeks to prevent display sleep that is due to user idleness. From the header for kIOPMAssertionTypeNoDisplaySleep: Deprecated in 10.7; Please use assertion type kIOPMAssertionTypePreventUserIdleDisplaySleep. From Apple Docs, kIOPMAssertionTypePreventUserIdleDisplaySleep is only available on 10.7 or later. I don't think kIOPMAssertionTypePreventUserIdleDisplaySleep will do anything on 10.6 As I suggested previously, I do want us to use PreventUserIdleDisplaySleep when it's available, so that's good. (Thank you for making that change.) What I'm saying now is mostly just that the comments are misleading. I suggest just removing the comments within the if. The code is understandable without them. Also, this bit of code uses tabs to indent when none of the rest does. Please be consistent with the surrounding code. Oops, I'll look into getting rid of those. Thanks, Ken
Re: x11drv: Return true when handling SPI_SETSCREENSAVEACTIVE
Perhaps a comment should be added so new people will know about it? On Jan 21, 2013, at 4:24 AM, Alexandre Julliard julli...@winehq.org wrote: C.W. Betts computer...@hotmail.com writes: I noticed in my research that the X11 driver doesn't return true in SystemParametersInfo when handling SPI_SETSCREENSAVEACTIVE. This patch fixes this. That's on purpose, it also needs to update the registry entry. -- Alexandre Julliard julli...@winehq.org
Re: macdrv: implement getting and setting the screen saver state.
On Jan 20, 2013, at 12:38 AM, Ken Thomases k...@codeweavers.com wrote:
Hi,
On Jan 19, 2013, at 4:08 PM, C.W. Betts wrote:
This implements getting and setting the screen saver state on the Mac Wine
driver.
Thanks for your contribution to the Mac driver. There are some issues with
the patch:
+CFDictionaryRef assertsionStats = NULL;
That variable name has a misspelling. It should probably be
assertionStates.
Fixed.
+CFNumberRef count =
CFDictionaryGetValue(assertsionStats, kIOPMAssertionTypeNoDisplaySleep);
+CFNumberRef count2 = NULL;
+long longCount = 0;
+long longCount2 = 0;
+CFNumberGetValue(count, kCFNumberLongType, longCount);
+count2 = CFDictionaryGetValue(assertsionStats,
kIOPMAssertionTypePreventUserIdleDisplaySleep);
+if(count2)
+CFNumberGetValue(count2, kCFNumberLongType,
longCount2);
Why are the two assertion types handled differently here? You get the value
in the initializer in one case but not in the other. You check if the
CFNumber pointer is NULL in one case but not the other. They should probably
both be handled the same way.
On Lion and later, kIOPMAssertionTypeNoDisplaySleep is deprecated in favor of
kIOPMAssertionTypePreventUserIdleDisplaySleep. This catches both: I don't know
if OS X Lion and later automatically maps kIOPMAssertionTypeNoDisplaySleep to
kIOPMAssertionTypePreventUserIdleDisplaySleep, so this takes care of both.
Some better variable names would be nice, too.
+if (longCount + longCount2 0)
If think it's better to use if (longCount || longCount2). We're really
interested in whether or not either is non-zero. If, somehow, the sum
overflows or one is a large negative value, we still want to consider that as
the screen saver being disabled.
+{
+*(BOOL *)ptr_param = FALSE;
+}
It's a minor style preference, but I prefer that single-statement bodies for
ifs not have braces.
Done.
+if(success != kIOReturnSuccess)
Another style nitpick: please put a space between if and the condition.
That applies to the if(count2) above, too.
Done.
+/*
+ Introduced in 10.6, not available in 10.5
+IOReturn success = IOPMAssertionCreateWithName(
+kIOPMAssertionTypeNoDisplaySleep,
kIOPMAssertionLevelOn,
+CFSTR(Wine Process requesting no screen saver),
powerAssertion);
+ */
To Alexandre's chagrin, the Mac driver requires 10.6. So, you might as well
use the newer function.
Done.
+IOReturn success =
IOPMAssertionCreate(kIOPMAssertionTypeNoDisplaySleep,
+kIOPMAssertionLevelOn, powerAssertion);
We should use kIOPMAssertionTypePreventUserIdleDisplaySleep instead on OS
versions where it's available. We could either check a framework version
variable (e.g. kCFCoreFoundationVersionNumber) or check if the dictionary
returned from IOPMCopyAssertionsStatus() contains
kIOPMAssertionTypePreventUserIdleDisplaySleep as a key.
I'll look into it.
+break;
This seems extraneous.
If you don't think there should be a break after a function returns, that's
okay: I just prefer to do that. Either way, done.
Cheers,
Ken
User driver function conventions
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. First is GetScreenStateActive. Does it check for if the screen saver is disabled for the whole system or just the app. And SetScreenStateActive. Is it supposed to set the activity for the whole system (I.E. if two apps call SetScreenStateActive to yes, then one to no, does the screen saver run) or is it per-app?
Re: User driver function conventions
I'm sorry if my intention was not clear: I want to implement this on vanilla Wine, I just did the initial work on CodeWeaver's code. But if the functions aren't on Vanilla, I guess there's no use pushing the patch here. On Jan 19, 2013, at 1:23 PM, Charles Davis cdavi...@gmail.com wrote: 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: User driver function conventions
Although, looking through the X11 Driver, there is a function that does check for the screen saver activity, it's just not two functions: SystemParametersInfo. I'll see if I can't get a patch put out. Also, what would be a good way to do this? Should I split the code into a new file or put it in macdrv_main.c? It does include a new header, as well as declare a static variable (Tell me if that's a no-no and I'll see if I can work around it). Also, the Mac driver would have to link to IOKit. On Jan 19, 2013, at 1:27 PM, C.W. Betts computer...@hotmail.com wrote: I'm sorry if my intention was not clear: I want to implement this on vanilla Wine, I just did the initial work on CodeWeaver's code. But if the functions aren't on Vanilla, I guess there's no use pushing the patch here. On Jan 19, 2013, at 1:23 PM, Charles Davis cdavi...@gmail.com wrote: 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
NTDLL doesn't compile under Clang
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 ^ inline asm:1:2: note: instantiated into assembly here div 12(%esp),%eax ^ I'm using Clang 2.0 from Xcode 4.0
Re: wineqtdecoder: initial commit of the video decoder using Mac OS/X QuickTime Framework
The main problem when using the QuickTime C APIs is that the majority, if not all of it, is deprecated and not available on 64-bit code. I would suggest using the Objective-C QTKit, but apparently Objective-C code is a no-no in Wine. On Nov 29, 2010, at 10:31 AM, Aric Stewart wrote: --- configure |8 +- configure.ac |5 + dlls/wineqtdecoder/Makefile.in| 11 + dlls/wineqtdecoder/main.c | 135 + dlls/wineqtdecoder/qtvdecoder.c | 536 + dlls/wineqtdecoder/version.rc | 26 ++ dlls/wineqtdecoder/wineqtdecoder.spec |4 + 7 files changed, 724 insertions(+), 1 deletions(-) create mode 100644 dlls/wineqtdecoder/Makefile.in create mode 100644 dlls/wineqtdecoder/main.c create mode 100644 dlls/wineqtdecoder/qtvdecoder.c create mode 100644 dlls/wineqtdecoder/version.rc create mode 100644 dlls/wineqtdecoder/wineqtdecoder.spec 89fa3b1cdaca45ec01cde9e2350010b82c985666.diff
Re: [PATCH 1/2] opencl: Initial stub implementation of OpenCL 1.0 (try 2)
It doesn't look like you look for Apple's OpenCL implementation, which uses OpenCL/opencl.h. You can do this: #ifdef __APPLE__ #include OpenCL/opencl.h #else #include CL/opencl.h #endif On Nov 29, 2010, at 7:39 AM, Peter Urbanec wrote: Resending because previous patch was mangled by Thunderbird. --- configure.ac| 13 dlls/opencl/Makefile.in |6 dlls/opencl/opencl.c| 29 ++ dlls/opencl/opencl.spec | 75 +++ 4 files changed, 123 insertions(+), 0 deletions(-) create mode 100644 dlls/opencl/Makefile.in create mode 100644 dlls/opencl/opencl.c create mode 100644 dlls/opencl/opencl.spec 0001-opencl-Initial-stub-implementation-of-OpenCL-1.0.patch
Re: Work on WineQuartz for MacOSX
If memory serves, the main reason why there hasn't been any work done is because of the dependency of Objective-C, which the project administrator has said no to. On May 16, 2010, at 9:31 AM, James Mckenzie wrote: All: There was or is a quite lengthy thread on this project. What is the status of work? Any progress on Emmanuel's work from 2008? Thank you. James McKenzie
Fwd: Work on WineQuartz for MacOSX
Begin forwarded message: From: Erich Hoover ehoo...@mines.edu Date: May 16, 2010 10:10:29 AM MDT To: C.W. Betts computer...@hotmail.com Subject: Re: Work on WineQuartz for MacOSX On Sun, May 16, 2010 at 10:02 AM, C.W. Betts computer...@hotmail.com wrote: If memory serves, the main reason why there hasn't been any work done is because of the dependency of Objective-C, which the project administrator has said no to. ... I don't know/remember if anyone brought this up previously, but there are ways to connect to an Objective-C library in a flat C project. I've been keeping this example handy in case I ever need to do it: http://www.smipple.net/snippet/moriyoshi/Using%20Objective-C%20ABI%20from%20within%20a%20pure%20C%20code. Erich Hoover ehoo...@mines.edu
Re: Work on WineQuartz for MacOSX
On May 16, 2010, at 12:29 PM, James Mckenzie wrote: C.W. The page referred to by this message no longer exists Time for an update. Include the period at the end. It works then. I was able to get the code and compile it fine under 32-bit mode. Apparently there has been a few changes in 64-bit mode that doesn't make it work quite as well. James McKenzie -Original Message- From: C.W. Betts computer...@hotmail.com Sent: May 16, 2010 10:06 AM To: wine-devel@winehq.org Subject: Fwd: Work on WineQuartz for MacOSX Begin forwarded message: From: Erich Hoover ehoo...@mines.edu Date: May 16, 2010 10:10:29 AM MDT To: C.W. Betts computer...@hotmail.com Subject: Re: Work on WineQuartz for MacOSX On Sun, May 16, 2010 at 10:02 AM, C.W. Betts computer...@hotmail.com wrote: If memory serves, the main reason why there hasn't been any work done is because of the dependency of Objective-C, which the project administrator has said no to. ... I don't know/remember if anyone brought this up previously, but there are ways to connect to an Objective-C library in a flat C project. I've been keeping this example handy in case I ever need to do it: http://www.smipple.net/snippet/moriyoshi/Using%20Objective-C%20ABI%20from%20within%20a%20pure%20C%20code. Erich Hoover ehoo...@mines.edu
Re: New SCSI Driver for Mac OS X
Excuse me, but why is this needed again? What IOCTL is missing in Mac OS X's native implementation? On Apr 27, 2010, at 2:10 PM, Charles Davis wrote: Hi, A while ago on this list, I was talking about implementing SCSI support on Mac OS X in Wine, and we all agreed the best way to do that would be to have a custom driver that provides an IOCTL interface. I've attached the driver (which is now finished) here. I've tested it on my system, and it works with this small test program that's also attached. But I want to make sure it's totally stable before I start working on the Wine side. So if you've got a Mac, and you're feeling brave, feel free to install my driver and run my test program. Extract the archive, then cd to the directory inside: tar jxf ExtMediaBSDClient.tar.bz2 cd ExtMediaBSDClient Install the extension to /Library/Extensions: cp -r ExtMediaBSDClient.kext /Library/Extensions If you're feeling really brave, you can install it to /System/Library/Extensions (and then it will be loaded on boot): cp -r ExtMediaBSDClient.kext /System/Library/Extensions The driver bundle has to be owned by root and belong to the wheel group, so make sure it does before trying to load it: sudo chown -R root:wheel /path/to/ExtMediaBSDClient.kext You can load the driver with the kextload command: kextload /path/to/ExtMediaBSDClient.kext You can verify that the driver loaded by running: kextstat | grep ExtMediaBSDClient Once it's loaded, all SCSI disks that are inserted afterward will accept the IOCTL. All disks that were inserted before won't however. To make sure a disk is using my driver, run the ioreg tool (it's part of Xcode) and look for ExtMediaBSDClient: ioreg | grep ExtMediaBSDClient To test it, run the program 'ExtMediaTest' that I included. Pass it the filename of a device file for the disk (it should be one of the raw device files, e.g. /dev/rdisk1 instead of /dev/disk1) on which you want to test this: ./ExtMediaTest /path/to/device/file If it works, the program will print some of the INQUIRY data for that disk to the Terminal. If it doesn't work, it will print an error to the Terminal (and the driver will have logged something in the kernel log; see the Console app), or worse, the kernel will panic. (If it says Inappropriate ioctl for device, that probably means it's not using my driver. Try ejecting the disk and reinserting it. And if it says the device is busy, try the program on one of the slices, e.g. /dev/rdisk1s1 instead of /dev/rdisk1.) If anything goes wrong (error messages, kernel panics, etc.), I want to know about it. If you get an error, paste the whole error message. If it's from ExtMediaTest, show me the lines in the kernel log that came from the driver (they have ExtMediaBSDClient or some such in them). If the kernel panics, attach the panic log. Also, tell me which version of Mac OS X you're using (so I know which KernelDebugKit to use). As soon as I verify that the driver works well, I'm going to start submitting patches to implement support for it in Wine. Chip ExtMediaBSDClient.tar.bz2
Re: DNS-sd Patch V.4
On Apr 22, 2010, at 1:09 PM, Hans Leidekker wrote: On Thu, 2010-04-22 at 11:56 -0600, C.W. Betts wrote: The Photoshop CS3 installer seems to stall during installation due to the lack of Bonjour (bug 15590). This patch attempts to fix it. No, it now succeeds in starting Bonjour, even if there's a native mdns server running (see comment #36). The problem is that when Bonjour finds that it can't do a wildcard bind it binds to specific addresses, thereby stealing traffic from the native server. My bad. Completely forgot about that. 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 making calls to the DLL? Or would the be making calls to the service? If they're making calls to the DLL, wouldn't something be needed to route those calls to the OS-native dns-sd implementation? Again, forgive my ignorance on this subject :/
ImageCapture Wine TWAIN plug-in
Anybody else up for the idea of an ImageCapture (Mac OS X) plug-in for Wine's TWAIN? It would fit the role of sane.ds and gphoto.ds, as it can both scan and access cameras. ImageCapture can also use Mac OS X TWAIN drivers.
Mac OS X technologies
There is a long list of technologies in Mac OS X that could be used to improve Wine on OS X. One of them is ColorSync. ColorSync is a color management software that is HEAVILY integrated into the Mac OS. For instance, you can calibrate your monitor and when OS X starts up, it will read the color profile file and adjust the graphics card output. It will also do color correction automatically in, e.g. Preview to get the best out of an image. However, I do not know how ColorSync influences Mac OS X's X11 system. It is possible that in order to take full advantage of ColorSync, a Mac OS X native front-end will need to be developed. Another interesting Mac OS X technology is Image Capture. This technology is used by the OS to scan images from a scanner as well as import images from a camera (iPhoto). It provides a wrapper around TWAIN drivers so they can be used by applications that don't support TWAIN. This is a purely C Framework. Although a sub-framework of the Carbon Framework, the functions are available in 64-bit code. This should not be confused with the ImageCaptureKit framework, which is most likely an Objective-c wrapper around the main Image Capture framework.
Re: win16 patches
As far as attribution goes, it was originally done by Jennifer Lai. My patch is more or less bringing these patches up to the current code. I am curious why these patches weren't applied in the first place. On Mar 31, 2010, at 6:58 PM, Juan Lang wrote: Hi C.W., this isn't going to fly. For one thing, diff --git a/dlls/kernel32/comm.c b/dlls/kernel32/comm.c index f4edfd3..a85f158 100644 --- a/dlls/kernel32/comm.c There's no attribution in this patch. It can't get committed without valid attribution. For another thing, one patch per email, please. One patch per email? Please elaborate. Do you mean per Wine component? For another, -if(!vga_text_console) +//if(!vga_text_console) C++ comments aren't allowed, and removing a line by commenting it out is frowned upon. If it's really not needed, just remove it. But you need to justify why it's no longer needed. More errors remain, but I'll stop at these. This set is well below acceptable yet, I'm afraid. --Juan
Re: [patch] DNS_SD bridge, v2
Excuse my ignorance, but what would happen if it didn't find the library dynamically? On Mar 16, 2010, at 4:03 AM, Marcus Meissner wrote: On Mon, Mar 15, 2010 at 04:36:32AM -0600, C.W. Betts wrote: The following is an updated patch that actually builds and links. The patch does patch configure and config.h.in, both of which were generated with an older version of autoconf and autoheader. You can and should leave out both configure and config.h.in from the diff, it is regenerated by Alexandre. - You use openal in a configure.ac warning messages instead of dns_sd. - how is non-presence of libdns_sd handled? It seems it will just fail to build then. It should load the called functions dynamically. Ciao, Marcus
Re: dns-sd dll implementation -- Needs work
On Feb 23, 2010, at 12:31 PM, Gert van den Berg wrote:Just a note: According to Wikipedia, Photoshop CS3 is among theapplications using Bonjour under Windows:http://blogs.adobe.com/jnack/2007/01/cs3_doesnt_inst.htmlGertAnd I read a bugzilla report that CS3 was having issues because of it.From what I can tell, DNS SD uses obscure structs and memory is allocated / deallocated using it's own functions. This wrapper wraps each function.I did edit the configure.ac file, but couldn't get autoconf to create a good configure file.Patch v2 attached dns-sd.diff Description: Binary data
Re: idea: display drivers
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
{
}
-(id)init;
-(void)dealloc;
@end
struct
{
WHQFunc *ObjC;
int ids;
}struct1;
@implementation WHQFunc
-(id)init
{
return [super init];
}
-(void)dealloc
{
[super dealloc];
}
@end
cfunc1()
{
}
cfunc2()
{
}
cfuncCreate(struct1 *s)
{
s = malloc(sizeof(struct1));
[[s-ObjC alloc] init];
}
cfuncDestroy (struct1 *s)
{
[s-ObjC release];
free(s);
}
On Feb 6, 2010, at 7:45 AM, James McKenzie wrote:
C.W. Betts wrote:
An idea that popped into my head when I was thinking about a Quartz (OS X)
driver that perhaps there could be separate drivers for Quartz (OS X) and
X11. Such drivers would include OpenGL and DirectX Drivers.
This has been shot down time and time again by Alexandre. However,
picking up the old Winequartz.dll code and looking at it has been a
project that I am interested in. The code is available from
Sourceforge.net.
James McKenzie
Re: [Darwine] RFC - wine-macos mailing list
If you could have it so that wine-macos is instantly sent to darwine-devel, and vice-versa.
