Re: AppDB: Rating / Patching
On Tue, Jan 6, 2009 at 11:03 AM, James Mckenzie wrote: > No, the appdb should not be touched. Rosanne said it correctly, ordinary > users are NOT going to take the time to build Wine, nor should they. We can > put in the bug report that the patch works and whether or not it has been > submitted. Sometimes a patch is to rough or a real hack that breaks other > programs, but with refinement is acceptable and will be incorporated into > Wine. The appdb needs to stay as clean as it can. Of course, you can always > add a bug report to the appdb entry, add comments and let users decide what > they want to do. Rating a rogue patched Wine as Gold is very misleading. We > need to keep ratings to what is available for the ordinary, unknowing user > (read nOOb.) Ok, I can see that nobody agrees with me here. I think the suggestion helps newbies *and* experts by keeping them sorted out. The situation where some reports are against patched versions and others arent, and you have to dig into the details to figure out which is which doesn't serve anybody. Excluding patched versions entirely is one way of solving the problem, but it seems to me that you're going to have a hard time stopping people from reporting results against patched versions. Binning all patched versions into "Bronze" isn't great, since some of us *do* want to know if we can make an app work with a patch, and in fact quite a few of us Linux users fall into that category. But anyway, I've made my argument and I'll drop it now. Cheers, -n8 -- Nathan Gray http://www.n8gray.org/
Re: AppDB: Rating / Patching
On Tue, Jan 6, 2009 at 10:12 AM, Austin English wrote: > On Tue, Jan 6, 2009 at 11:42 AM, Nathaniel Gray wrote: >> It sounds like the problem is that the version string in appdb isn't >> descriptive enough. It's perfectly reasonable to wonder if a given >> program can be made to work with a patched version of wine, and wonder >> how well it will work. It's also reasonable to wonder how it will >> work with a vanilla version. Both types of reports are useful to have >> in the appdb. Having a version "x.x.x (patched)" available to >> reporters would allow both types of reports to be clearly separated. > > No. Because that allows for all sorts of dirty hacks, and is confusing > to users. Ratings should specify default wine. They can list patches, > etc., in the comments, with a note of how well it works. It seems to me that digging through comments to find out if a report refers to a version that was patched is more confusing than having it advertised right up front in the version string. And it makes sense -- a patched 1.1.11 is not the same *version* as 1.1.11. Cheers, -n8 -- Nathan Gray http://www.n8gray.org/
Re: AppDB: Rating / Patching
On Tue, Jan 6, 2009 at 10:15 AM, Rosanne DiMesio wrote: >> >> It sounds like the problem is that the version string in appdb isn't >> descriptive enough. It's perfectly reasonable to wonder if a given >> program can be made to work with a patched version of wine, and wonder >> how well it will work. It's also reasonable to wonder how it will >> work with a vanilla version. Both types of reports are useful to have >> in the appdb. Having a version "x.x.x (patched)" available to >> reporters would allow both types of reports to be clearly separated. >> > > Patched with what? Lumping all the different possibilities into one "version" > is also misleading. Perfect information isn't necessary here. It's just useful to know what kind of performance you can get if you decide to venture into the world of patching and recompiling. Experts will know if it's worth their time, newbies will know to stay away. Cheers, -n8 -- Nathan Gray http://www.n8gray.org/
Re: AppDB: Rating / Patching
On Tue, Jan 6, 2009 at 6:48 AM, Rosanne DiMesio wrote: > >> Now, the story changes if the patch is conforming and has been accepted >> by AJ and is pending the next development release. >> > Then the next development release can get the gold, but previous ones still > shouldn't. AppDB test ratings are tied to specific releases, and intended to > tell normal users how different versions of Wine will work with their app. > Patching Wine is not something normal users can or want to do, and allowing > ratings based on patched versions of Wine is misleading, even if the patch > does eventually make it in to a later release. It sounds like the problem is that the version string in appdb isn't descriptive enough. It's perfectly reasonable to wonder if a given program can be made to work with a patched version of wine, and wonder how well it will work. It's also reasonable to wonder how it will work with a vanilla version. Both types of reports are useful to have in the appdb. Having a version "x.x.x (patched)" available to reporters would allow both types of reports to be clearly separated. Cheers, -n8 -- Nathan Gray http://www.n8gray.org/
Re: Linking to a Mac OS X build of Wine from winehq.org/download ?
On Sun, Dec 21, 2008 at 8:38 AM, Dan Kegel wrote: > On Sun, Dec 21, 2008 at 8:27 AM, Roderick Colenbrander > wrote: >>> Say, http://www.kronenberg.org/darwine/ seems to be a popular source >>> of nearly up to date wine builds for the mac. How about we link to it >>> from http://winehq.org/download/ ? >>> >>> Furthermore, are his packages good enough to support? >>> If so, how 'bout we ask him to add links to bugzilla and >>> the appdb from his page? >> >> Most importantly we need to get rid of the Darwine name. It causes a lot of >> unneeded confusion. > > Yes, I would like to keep Darwine as the name of the old powerpc project > that combined an x86 emulator and wine. > > Can we convince Mike and Zach to switch names to just plain Wine? As one who just spent several days trying to figure this stuff out and still isn't quite sure he got it right, I'd like to add "pretty please?" Cheers, -n8 -- Nathan Gray http://www.n8gray.org/
Re: Adding Mac joystick support -- build problem
On Sat, Dec 20, 2008 at 9:21 PM, Nick Burns wrote: > > I have a few tips for running built wine on OS XI have been working on > getting SHOGO to run (I have one more patch to send up) Hey, thanks for the patch, I'll give it a shot! I also realized that Mike K. provides his build environment and some nice scripts so I've been trying them out as well, but still without success. One thing I've found is that I can replace the dinput.dll from Mike K's build with one of mine without problems, so that may be a way for me to work on the joystick support even if I can't manage to get the whole build working properly. Cheers, -n8 -- Nathan Gray http://www.n8gray.org/
Re: Adding Mac joystick support -- build problem
Sorry to reply to self, but I forgot to mention I'm running OS X 10.5.5. -- Nathan Gray http://www.n8gray.org/
Adding Mac joystick support -- build problem
Hi wine-devels, I've got a simple goal. I want to play IL-2 Sturmovik on my Mac without rebooting. This flight sim is gold-rated in the app-db, so this should be a walk in the park, but of course the game does require a joystick. After a bit of poking I realized that there's no support for joysticks under Mac OS. I'm willing to write the code for joystick support, and I've even gotten as far as writing a test app under OS X that enumerates all joysticks and polls their state. I've looked at the linux joystick code in wine and think I can write the equivalent code for OS X. What I *can't* seem to do is build a wine that can run IL-2. I've had no problem installing and playing the demo using the 1.1.9 build at http://www.kronenberg.org/darwine/ and using crossover games, but when I build wine myself the IL-2 demo installer fails to run. I've tried building the 1.1.9 and 1.1.10 tarballs and using macports to install 1.1.10, all with the same result: --- begin log output --- Could not load Mozilla. HTML rendering will be disabled. err:wgl:has_opengl glx_version is 1.2 and GLX_SGIX_fbconfig extension is unsupported. Expect problems. wine: configuration in '/Users/n8gray/.wine' has been updated. err:ntdll:RtlpWaitForCriticalSection section 0x7bc8a384 "loader.c: loader_section" wait timed out in thread 0024, blocked by 0023, retrying (60 sec) wine: Unhandled page fault on read access to 0x at address 0x1017:0x0c1d (thread 0025), starting debugger... couldn't load main module (2) Unhandled exception: page fault on read access to 0x in 32-bit code (1017:0c1d). In 32 bit mode. Register dump: CS:1017 SS:1217 DS:1217 ES:11ef FS:11ff GS:0037 EIP:0c1d ESP:56ee EBP: EFLAGS:00010202( - 00 - -RI1) EAX:0001 EBX:0080 ECX:19b0 EDX:0001 ESI: EDI:1217 Stack dump: 0x1217:0x56ee: f160 7b88 7597 120f 0468 0x1217:0x56fe: 1027 0x1217:0x570e: 023f: sel=11ff base=7eed limit= 32-bit rw- Backtrace: =>1 0x1017:0x0c1d (0x1217:0x) 0x1017:0x0c1d: call 0xfffe Modules: Module Address Debug info Name (7 modules) PE 6018-60184000 Deferredadvapi32 PE 6031-60325000 Deferreduser32 PE 604b-604b4000 Deferredgdi32 PE 61cc-61d0d000 Deferredwinmm PE 622a-622a4000 Deferredversion PE 7b81-7b889000 Deferredkernel32 PE 7bc1-7bc14000 Deferredntdll Threads: process tid prio (all id:s are in hex) 000c 001f0 001e0 00180 00170 000e0 000d0 0010 00110 001b 00210 00200 001d0 001c0 0022 (D) C:\windows\system32\winevdm.exe 00250 <== 00240 00230 Backtrace: =>1 0x1017:0x0c1d (0x1217:0x) err:ntdll:RtlpWaitForCriticalSection section 0x7b92c250 "syslevel.c: Win16Mutex" wait timed out in thread 0023, blocked by 0025, retrying (60 sec) --- end log output --- If I use Mike's build I only get these messages: wine: created the configuration directory '/Users/n8gray/.wine' Could not load Mozilla. HTML rendering will be disabled. wine: configuration in '/Users/n8gray/.wine' has been updated. Clearly there's some magic build juju that I don't have, perhaps related to opengl. I've read the wiki, but I haven't found anything that I haven't already tried. Can anybody provide a hint as to how to get this working? BTW, I'm using the latest XQuartz 2.3.2_rc3 (xorg-server 1.4.2-apple27). Thanks, -n8 -- Nathan Gray http://www.n8gray.org/
Re: VST wrapper
On Jun 25, 2007, at 6:01 AM, Dan Kegel wrote: Hi N8, [How can I write a shared library that uses Wine and can be called from a non-winelib app?] This is a somewhat frequently asked question. I did try to find the answer in the documentation before posting here but couldn't find anything. As Stephan explained, wine's code requires that the process have been set up somewhat specially. This is taken care of by the sources in the loader subdirectory. In a perfect world, some of that code would move into the operating system's process loader... then one could mix and match win32 and unix calls more easily. Anyway, knowing about the code in that directory is key to understanding why what you ask is hard, and in finding a workaround. Ok, I guess it's not simple, which is what I wanted to know. I don't have time to become an expert in loading/linking windows programs, so I suppose I can live with an IPC-based solution. Thanks for the help, and thanks to Stefan and Tom as well. -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
Re: VST wrapper
By the way, please CC me with replies. I'm not set up to receive mail from the list. Thanks, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
VST wrapper
Hi, I'm interested in the goal of using Windows VST/VSTi audio plugins on my Intel Mac in OS X. I found the fst project, did some porting, and managed to get a few VSTs to work, which had me pretty stoked. Thanks to the FST folks and the Wine team for making this possible! On the other hand, I'd rather have the option of running the plugins in-process with my DAW software instead of as separate processes connected by JACK. I can imagine a super-thin layer of code that just translates calls between the plugin and the host and allows the plugin to access the Win32 API. In case I'm being unclear, here's how it breaks down. There's a host application that's native OS X and knows nothing about Wine. I'd like to write a plugin that, when it's loaded, will load a windows dll. The host will call into the plugin, which will call into the dll. The dll will make upcalls to the plugin, which will in turn call up to the host. The dll will probably be running a windows gui as well and making calls to various windows APIs. So is this possible? I'm pretty new to Wine and Windows programming so forgive me if the answer to this question is obvious. I've seen plenty of examples of how to build and run .exes that are windows programs from the ground up, but I've never seen wine used as part of a plugin. If it's possible, can you point me to any examples? What are the relevant parts of Wine I should look at? Thanks, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
