Re: msctf: add internal function for handling TfClientIds
Alexandre Julliard julli...@winehq.org wrote on Feb 23:
Aric Stewart a...@codeweavers.com writes:
+/* If i understand this correctly at most a process should generate
+ * only a handful of these... But in case I am wrong */
+if (id_last == 65535)
+{
+ERR(TfClientIds generated exceeds USHORT limit\n);
+return 0x0;
+}
+id_last++;
+id-id = MAKELONG(id_last, magic);
+id-data = data;
+list_add_head(clientids,id-entry);
Using an array index would be cleaner than having to search through the
list everytime you use an id.
Also, aren't linked lists inefficient as well. Searching through them can be
very intense, unless they are small ( 5 elements). Anything larger than this
and an array would be more efficient.
James McKenzie
Re: msacm32: acmFormatEnum - implementing ACM_FORMATENUMF_SUGGEST (2nd try)
Stefano Guidoni wrote: This patch implements ACM_FORMATENUMF_SUGGEST and fixes bug 16394. From MSDN: The WAVEFORMATEX structure pointed to by the pwfx member of the ACMFORMATDETAILS structure is valid. The enumerator will enumerate all suggested destination formats for the given pwfx format.. Since the WAVEFORMATEX structure is valid, there is no need to cycle through all the standard formats (moreover the WAVEFORMATEX format could be not a standard one). _ S. Guidoni Can you please use standard compression programs with standard extensions. Your file extension, .bin will not work here. James McKenzie
Re: D3D: Implement vertex blending in drawStridedSlow
Claudio Ciccani wrote: Il giorno lun, 26/01/2009 alle 12.12 +0100, Claudio Ciccani ha scritto: Il giorno dom, 25/01/2009 alle 23.19 +0100, David Adam ha scritto: 2009/1/25 Claudio Ciccani k...@users.sf.net The patch implements a software fallback for vertex blending in drawStridedSlow, fixing Bug #6955. Although vertex blending is an old and outdated extension, there are still many applications(games) relying on it nowadays. This because the extension is generally supported by Direct3D, either directly in hardware (using vertex programs) or in software. This patch makes NOLF2 demo crashes. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7e6095c7 ESP:0033f0b4 EBP:0033f1ec EFLAGS:00010246( - 00 -RIZP1) EAX:00ec1b28 EBX:7e6bbc54 ECX:014c EDX: ESI:0048 EDI: Stack dump: 0x0033f0b4: 3f80 0x0033f0c4: 0033f110 7d05e000 7c03d008 7c7aa346 0x0033f0d4: 0003 7e6bc7a0 7e69ee95 0x0033f0e4: 7e69e648 0001 000c 0010 0x0033f0f4: 795a5f68 7d09c0ac 0002d008 00ebd44c 0x0033f104: 00eba698 00ebd7a8 0007 Backtrace: =0 0x7e6095c7 drawStridedSlow+0x697(iface=0xeba698, sd=0xebd44c, NumVertexes=72, glPrimType=4, idxData=0x31dca00, idxSize=2, minIndex=0, startIdx=0) [/home/david/wine/dlls/wined3d/drawprim.c:307] in wined3d (0x0033f1ec) 1 0x7e60ea1b drawPrimitive+0x101b(iface=0xeba698, PrimitiveType=4, NumPrimitives=24, numberOfVertices=24, StartIdx=0, idxSize=is not available, idxData=(nil), minIndex=0) [/home/david/wine/dlls/wined3d/drawprim.c:1024] in wined3d (0x0033f55c) 2 0x7e5e41f9 IWineD3DDeviceImpl_DrawIndexedPrimitive +0xe9(iface=0xeba698, PrimitiveType=WINED3DPT_TRIANGLELIST, minIndex=0, NumVertices=24, startIndex=0, primCount=24) [/home/david/wine/dlls/wined3d/device.c:5314] in wined3d (0x0033f5cc) 3 0x7e6d43b6 IDirect3DDevice8Impl_DrawIndexedPrimitive +0x96(iface=register ESI not in topmost frame, PrimitiveType=D3DPT_TRIANGLELIST, MinVertexIndex=0, NumVertices=24, startIndex=0, primCount=24) [/home/david/wine/dlls/d3d8/device.c:1419] in d3d8 (0x0033f5fc) 0x7e6095c7 drawStridedSlow+0x697 [/home/david/wine/dlls/wined3d/drawprim.c:307] in wined3d: flds 0x0(%ecx) 307 m = stateBlock-transforms[WINED3DTS_WORLDMATRIX((indices ? indices[0] : 0))].u.m[0][0]; Modules: Really strange! Tested the patch against other games and it worked. With NOLF2 I'm getting a crash too, but at a different location: 1 0x7e6217ca drawPrimitive+0x112a(iface=0xec7660, PrimitiveType=4, NumPrimitives=18, numberOfVertices=20, StartIdx=0, idxSize=2, idxData=0x3d871e0, minIndex=0) [/home/klan/src/wine/dlls/wined3d/drawprim.c:540] in wined3d (0x) 0x7d2b3771: movl0x0(%ecx),%edx 540 for (texture = 0; tmp_tex_mask; tmp_tex_mask = 1, ++texture) I found that the reason of the crash was that VBOs were not removed when using drawStridedSlow for vertex blending. Attached is the modified patch, which doesn't make NOLF2 crash. Patches have to be submitted to Wine-patches. James McKenzie
Re: [RFC] named pipe message-mode design
Luke Kenneth Casson Leighton wrote: On Wed, Mar 4, 2009 at 6:10 PM, Alexandre Julliard julli...@winehq.org wrote: Luke Kenneth Casson Leighton l...@lkcl.net writes: i would imagine that inefficient is the _last_ thing on the list of priorities. technically correctly fulfilling the semantics i would imagine would be the highest priority. efficient and nice can always be done later, yes? No, in many cases efficiency needs to be taken into account in the design phase. You can't just add it later. sure you can. by redesigning. Since I deal with that on a daily basis, I'll step in. A great design is one that does EVERYTHING right the first time. What you are proposing goes counter to this and is unacceptable. Do it right the first time and you don't have to revisit, revisit and revisit some more. In other words: AJ is right, you are just looking for the easy way out. Not a good idea and others end up cleaning up when the users start whining. James McKenzie
Re: makedep: let umask decide mode for Makefiles
Dan Kegel wrote: Paul Bryan Roberts write: The code as it stands creates makefiles with a mode of 600. This may be benign on most (e.g. personal workstation) installations but not all. An example is where the wine git repository is located on an NFS volume. Here security settings may mean that root:root is treated as nobody:nogroup. Installation from the repository is not possible as root (whether via su or sudo) cannot even read the makefiles Where I work, NFS is set up so root cannot access any NFS volumes, period, because you really can't trust remote systems that much with NFS. Just as an aside, where I work, world write is highly discouraged and must be removed unless absolutely necessary. James McKenzie
Re: AppDB entries are being delete without contacting maintainer by Rozanne
Austin English austinengl...@gmail.com wrote on March 6: Sent: Mar 6, 2009 1:42 PM To: Klaus Layer klaus.la...@gmx.de, Rosanne DiMesio dime...@earthlink.net Cc: Wine Develop wine-devel@winehq.org Subject: Re: AppDB entries are being delete without contacting maintainer by Rozanne On Fri, Mar 6, 2009 at 2:36 PM, Klaus Layer klaus.la...@gmx.de wrote: Hi all, since several months a user Rozanne is changing AppDB entries without contacting the maintainers. Most of the changes so far were minor changes. But today I was informed that Rozanne just deleted an entry which was maintained by me. According to the email I received, there were duplicated entries for the programm Mapsource. I regard deleting entries from Appdb without giving the maintainer a chance to backup what they maintained a *very* unfriendly act. I would have merged the two entries under one to save the valuable information users added to AppDB. Just deleting entries from AppDB, deletes information the wine community collected to support using wine. Users spent a lot of time and just deleting their work is *not* acceptable. Can someone of the adminstrators of AppDB please make sure that Rozanne stops deleting entries from AppDB without informing the maintainers before. I would expect to be informed about such an action before and that I as a maintainer have the right to discuss was is being delete and what not. Thanks, Klaus -- Forwarded message -- From: AppDB appdb-nore...@winehq.org To: appdb-nore...@winehq.org Date: Fri, 06 Mar 2009 08:42:12 -0600 Subject: [AppDB] Submitter screenshots deleted Submitter screenshots deleted --- The screenshots you submitted for MapSource 6.13.7 have been deleted because MapSource 6.13.7 was deleted. The action was performed by Rosanne Reasons given The parent entry was deleted. The reason given for that deletion was: Duplicate entry Best regards. The AppDB team http://appdb.winehq.org/ If you don't want to receive any other e-mail, please change your preferences: http://appdb.winehq.org/preferences.php Well, Rozanne _is_ an AppDB administrator, hence the permission to delete those entries. That said, yes, notice should be given. Also, please be aware that entries referring to ReactOS, PlayonLinux and Crossover are also being removed. The latter is actually biting the hand that feeds us. CodeWeavers, the producers of Crossover, host WineHQ. What might be a better idea is to state: This program has been shown to work better with Crossover, please visit their web site for more details. Please be aware that Crossover is a commercial product whose developers also support Wine. James McKenzie
Re: AppDB entries are being delete without contacting maintainer by Rozanne
Austin English austinengl...@gmail.com wrote on March 6th: Sent: Mar 6, 2009 4:47 PM To: James Mckenzie jjmckenzi...@earthlink.net Cc: Wine Develop wine-devel@winehq.org Subject: Re: AppDB entries are being delete without contacting maintainer by Rozanne On Fri, Mar 6, 2009 at 3:44 PM, James Mckenzie jjmckenzi...@earthlink.net wrote: Austin English austinengl...@gmail.com wrote on March 6: Sent: Mar 6, 2009 1:42 PM To: Klaus Layer klaus.la...@gmx.de, Rosanne DiMesio dime...@earthlink.net Cc: Wine Develop wine-devel@winehq.org Subject: Re: AppDB entries are being delete without contacting maintainer by Rozanne On Fri, Mar 6, 2009 at 2:36 PM, Klaus Layer klaus.la...@gmx.de wrote: Hi all, since several months a user Rozanne is changing AppDB entries without contacting the maintainers. Most of the changes so far were minor changes. But today I was informed that Rozanne just deleted an entry which was maintained by me. According to the email I received, there were duplicated entries for the programm Mapsource. I regard deleting entries from Appdb without giving the maintainer a chance to backup what they maintained a *very* unfriendly act. I would have merged the two entries under one to save the valuable information users added to AppDB. Just deleting entries from AppDB, deletes information the wine community collected to support using wine. Users spent a lot of time and just deleting their work is *not* acceptable. Can someone of the adminstrators of AppDB please make sure that Rozanne stops deleting entries from AppDB without informing the maintainers before. I would expect to be informed about such an action before and that I as a maintainer have the right to discuss was is being delete and what not. Thanks, Klaus -- Forwarded message -- From: AppDB appdb-nore...@winehq.org To: appdb-nore...@winehq.org Date: Fri, 06 Mar 2009 08:42:12 -0600 Subject: [AppDB] Submitter screenshots deleted Submitter screenshots deleted --- The screenshots you submitted for MapSource 6.13.7 have been deleted because MapSource 6.13.7 was deleted. The action was performed by Rosanne Reasons given The parent entry was deleted. The reason given for that deletion was: Duplicate entry Best regards. The AppDB team http://appdb.winehq.org/ If you don't want to receive any other e-mail, please change your preferences: http://appdb.winehq.org/preferences.php Well, Rozanne _is_ an AppDB administrator, hence the permission to delete those entries. That said, yes, notice should be given. Also, please be aware that entries referring to ReactOS, PlayonLinux and Crossover are also being removed. The latter is actually biting the hand that feeds us. CodeWeavers, the producers of Crossover, host WineHQ. What might be a better idea is to state: This program has been shown to work better with Crossover, please visit their web site for more details. Please be aware that Crossover is a commercial product whose developers also support Wine. James McKenzie Codeweavers has their own AppDB type system: I am very well aware that this exists. However, folks with Wine may NOT. Putting a pointer in the AppDB for those programs that need a lot of work to run under Wine may prove helpful (remember that is the purpose of this system to get users to get their favorite Windows program running under Linux/UNIX.) We also have to remember that some folks picked up Linux/Wine because it is FREE, and sending them off to a product that may cost them money will just get the upset unless we 'warn' them first. So, my suggestion is just that, a suggestion. However, I have found that one of my favorite First Person Shooters will NOT run under Wine. No problem as it does with CrossOver (and it is actually worse under CrossOver Games for Mac), so I have it and I use it. The problem that causes the game to fail is outside of the scope of the Wine project, as CodeWeavers worked around the busted OpenGL in Apple's/XQuartz's X11 implementation. Thus if I were to write up the program under Wine it would be Garbage with a cavat that it does work under Crossover Mac. This is NOT needed for Linux as it runs just fine under most, if not all distros. I don't know or care about ReactOS or PlayOnLinux's abilities at this time. I would NOT like to see them in the AppDB for a number of reasons, mostly legal. It might also be possible to put the existance of CrossOver in the first page, but that would be up to the web masters. James McKenzie
Re: AppDB entries are being delete without contacting maintainer by Rozanne
Ben Klein wrote: 2009/3/7 James Mckenzie jjmckenzi...@earthlink.net: Also, please be aware that entries referring to ReactOS, PlayonLinux and Crossover are also being removed. The latter is actually biting the hand that feeds us. CodeWeavers, the producers of Crossover, host WineHQ. What might be a better idea is to state: It's not biting the hand that feed us. We don't want Crossover AppDB data in Wine's AppDB, just like Crossover doesn't want Wine's AppDB data in their AppDB. Ben: CodeWeavers provides a great deal of support and fixes for Wine. Let us not forget this. Second, yes this should be a USER comment. I for one cannot run any of the dOOm games on my Intel Mac. The reason is that the OpenGL support from Apple and the XQuartz project is not 'up to snuff' for Wine. However, CrossOver Office and CrossOver Games will run these games. Why the code has not made it back into Wine is not my decision. So, if I were to write up an entry for these games, I would rate the game(s) Garbage with the note above. I would hope that this would be enough of an explanation, for now. If XQuartz were to release a version that did incorporate appropriate OpenGL code, I would retest and re-evaluate. This might result in an upgrade of my evaluation, or it might not fix the problem. However, we should not just remove Crossover ratings, unless they are full blown writeups and then it might be prudent to just remove the evaluation and state that one exists (or should) on the Crossover site. This should only be done if the program cannot be run under Wine or takes extensive amounts of time and effort to do so. Of course, this is my opinion. We also have to give users the truth. If a program is broken in Wine but runs just fine in Crossover, we should at least tell them that this is so. Maybe this will influence a developer or two to figure out the problem and fix it. James McKenzie
Re: AppDB entries are being delete without contacting maintainer by Rozanne
Ben Klein wrote: [cut to conserve space and to get to the point] appdb.winehq.org is for Wine application test data. If a user submits test data that says Garbage in Wine, with an additional comment that says I was able to get this working in Crossover Office, I don't have a problem. However, if the test data is entirely for Crossover, or RecatOS, Cedega or WineX for that matter, it does not belong on AppDB. I agree with the use of the Wine Applications Database with these restrictions. I don't want to see products listed that do not conform to the same standards as Wine. Rating: Garbage What works: Installer What doesn't work: Starting the game What wasn't tested: N/A Additional comments: This works in Crossover Games, but not in Wine ^^ I don't have a problem with this. (If it mentioned Cedega/WineX or ReactOS, I'd probably remove the additional comment, but leave the test data intact. CodeWeavers products are a special case :) ) I think this is the point. Crossover, yes. The rest of the stuff, no. And this is exactly what I was talking about. If it does not work in Wine, rating: Garbage, not Plat, Gold or Bronze. James McKenzie
Re: AppDB entries are being delete without contacting maintainer by Rozanne
Sparr wrote: On Fri, Mar 6, 2009 at 11:39 PM, Ben Klein shackl...@gmail.com wrote: Rating: Garbage What works: Installer What doesn't work: Starting the game What wasn't tested: N/A Additional comments: This works in Crossover Games, but not in Wine ^^ I don't have a problem with this. (If it mentioned Cedega/WineX or ReactOS, I'd probably remove the additional comment, but leave the test data intact. CodeWeavers products are a special case :) ) As a user, I take offense to the favoritism showed here. Codeweavers buying things for winehq should not negatively impact the usefulness of the service for non-codeweavers users. That is, if I pay for Cedega but not for Crossover, why is winehq discriminating against me in terms of what comments it allows? Codeweavers supports Wine and provides a lot of assistance with fixing bugs. I have not seen a Cedega provide a patch in a long time. James McKenzie
Re: Fwd: [Wine] Re: The pros and cons of a wiki AppDB
David: Would you be willing to clean out the ash and trash that will show up with an open Wiki? I don't have the time to do this and it REALLY sounds like you are volunteering since you are pushing this issue so hard. See there are VALID reasons for doing things the way we do them. BTW, I am a maintainer of exactly ONE application. I've worked with this application and would really like to get one feature working. Why am I supporting that application? This is because the author refuses to release source code and he will not be building a Mac/Linux specific version. James McKenzie -Original Message- From: David Gerard dger...@gmail.com Sent: Mar 8, 2009 6:59 AM To: Wine Develop wine-devel@winehq.org Subject: Fwd: [Wine] Re: The pros and cons of a wiki AppDB The current appdb system doesn't actually work. Example below. -- Forwarded message -- From: fcmartins wineforum-u...@winehq.org Date: 2009/3/8 Subject: [Wine] Re: The pros and cons of a wiki AppDB To: wine-us...@winehq.org Well, I can certainly confirm there is a barrier for drive by submissions. As a matter of fact the barrier is even bigger than one might anticipate (as an occasional user): - sometime ago I submitted test data for a game. It was rejected with: Please fill the What does not work. I had written something like: I've done only initial gameplay. I believe the reply was implicitly there, so IMO it was a unneeded barrier. Anyway, I tried to oblige with a more explicit reply, and guess what: the submission was not working: After submit, the form came back with the old data!! So, another barrier. Furtermore, I sent an email to webmaster with the issue, but never heard anything back. As you can imagine, this has lowered my willingness to submit test data, and lack of updated info for newer versions of wine is THE major problem with appdb. On the positive side, I had two comments in Sacred deleted by the maintainer as a cleanup, and I felt the deletes were appropriate and educative. Anyway, I think appdb mostly works and putting a wiki as a full replacement would be a mistake. As it is, appdb has maybe a tiny bit too much structure and bureaucracy, but going to the wiki and loose all the structure would be silly. The UI and function of appdb is mostly quite good: I would look for small tweaks lowering the barrier for contributions: some areas could work like a wiki: the description, screenshots, and an always present howto. The howto should be always editable and invite people to improve it with their own tweaks, minimising the user having to go through the comments to find a possibly inexistent needle. I would definitely look into a simpler form to submit test data, but above all, I would look into having one of those wine appdb love days (weeks) were test data is put up to date, e.g. for a forthcoming 1.2?
Re: [Wine] The pros and cons of a wiki AppDB
-Original Message- From: David Gerard dger...@gmail.com Sent: Mar 8, 2009 6:59 AM To: wine-devel@winehq.org Cc: Wine wine-us...@winehq.org Subject: Re: [Wine] The pros and cons of a wiki AppDB 2009/3/7 IneedAname wineap...@googlemail.com: On Sat, 7 Mar 2009 20:10:13 + David Gerard dger...@gmail.com wrote: Yep. That's why a wiki is nice. If you open it up to everyone to contribute, you'll get bad stuff but you'll get good stuff you just wouldn't get otherwise. It's a great format to capture that. We would use the same system for edit rights that we use now. Make appDB account then ask to be a maintainer then you can edit the wiki page for that app. The wiki is only for application notes. Anyone can read the wiki history. Con: It would be very hard to set up. Con: Becoming a maintainer is a pain in the backside. You won't get useful drive-by contributions, and a lot of this stuff is drive-by. Example? I've been a maintainer for over a year now. I've received two postings for the program. I don't think a lot of Linux and Mac users are using the program, or they are not experiencing problems. I will update the entry, now that you have reminded me to do so. Do not cross post or you may up set people with power. So when we're talking about a service to users, you're saying God forbid we ask the users? We are discussing what is a development issue. We really don't need to confuse users with this. Besides, I don't think most users really care if we are using a Wiki or a Web Application to record what is hsppening with Applications and their ability to run on Wine. James McKenzie - d.
Re: Fwd: [Wine] Re: The pros and cons of a wiki AppDB
David Gerard dger...@gmail.com wrote on March 8th: 2009/3/8 James Mckenzie jjmckenzi...@earthlink.net: Would you be willing to clean out the ash and trash that will show up with an open Wiki? I already said I would, yes - that the only reason for not just starting one is to avoid massive duplication of effort. If we move to an open Wiki, be prepared to be very busy. I've seen spambots get past most, if not all, of the verification systems and bomb away. I've read where several systems had to shut them down for fear of being sued. At the present time, we have verification for exactly that reason. To keep the spam out and to pre-edit those entries that do not provide all of the information needed. I don't have the time to do this and it REALLY sounds like you are volunteering since you are pushing this issue so hard. See there are VALID reasons for doing things the way we do them. I'm sure there are. I would love to see a Wiki, with pre-editing of the entries. This is possible, but would not address the problem you raised. James McKenzie
Re: [PATCH] [RFC] Make drive C always a
King InuYasha ngomp...@gmail.com wrote on March 8th: It is definitely possible for Drive C: to be a network share on all versions of Windows starting from Windows 95. This does not exempt Windows XP/Vista/2k3/2k8. In fact, a public library in Indiana that I used to go to before I moved has all their machines set up this way. It takes a LOT of tweaking to make it work properly, because some applications expect Windows on Drive C:, but it is possible to do it. I think this is how Fedex Office (formerly FedEx Kinkos) does it. I know that one of the local university's was also looking into this to prevent spread of viruses and to prevent 'file sharing'. This is absolutely possible and programs should support installation to a network share as C:. Windows can also be run this way. Rather than set C: as Fixed, Wine should be set so that C: can be a network share that is NOT removable. This will take effort. Sometimes the easy solution is not the correct one. James McKenzie
Re: Sufficient 1.2 release criterion: passing all tests on all platforms?
Dan Kegel d...@kegel.com wrote on March 8th: It almost feels within our grasp for midyear... how 'bout it? I would like to add that these tests should also pass on the MacOSX platform as well. +1 to the idea, Dan. James McKenzie
Re: Vacations
Alexandre Julliard wrote: Folks, There won't be any commits next week, as I'll be skiing... Happy skiing and stay safe and warm. James McKenzie
Re: riched20: add tests for EM_FORMATRANGE
Lei Zhang wrote: On Fri, Mar 13, 2009 at 12:01 PM, Paul Vriens paul.vriens.w...@gmail.com wrote: Lei Zhang wrote: Hi, In my last attempt, I submitted Troy Rollo's EM_FORMATRANGE implementation and with my test cases. I'm not sure what was wrong with the implementation, but the test cases should be ok. Hi Lei, Pretty old patch. (June 2007) I just moved some of my VMware 'boxes' to my new laptop (laptop resolution 1024x800) and I suddenly had some failures. The resolution that VMware can use (with all those borders and the sidebar) is 1044x574. Running the tests fullscreen makes them pass again. You can replicate this by playing with the screen resolution. The smaller the resolution the more test failures. Any idea where I need to look? -- Cheers, Paul. Is this on Windows in VMWare? I'm not getting any riched20 crosstest failures here at 800x600. Interesting that this should fail on a VMWare workstation setup. The tests are pretty straightfoward. Also, I have not worked on this due to other pressures of life. Would someone like to take this over and finish it? This would solve a couple of open bug reports and fix some complaints about text rendering. James McKenzie
Re: [riched20/tests] Changed tests for EM_FORMATRANGE
Paul Vriens paul.vriens.w...@gmail.com wrote on March 16th: Hi, I've been playing with this and just wanted to see if anybody has comments on these changed tests. Tests succeed on Win95/Win98 and W2K3 with every possible resolution (as we are not relying on the resolution anymore) and 96/120 dpi. Paul: Looks good to me. I still need someone to pick up the actual implementation code and work with it. I have other priorities right now and think that Tony Rollo's code will not work and will require major rework to function properly with RichOLE. James McKenzie
Re: 16bit code generation
Ben Klein wrote: Oops, missed reply-to-all. 2009/3/22 Tijl Coosemans t...@ulyssis.org: I was reading through binutils documentation and came across this. Maybe it can be used to compile 16 bit tests. 3.2.4. 16-bit mode Binutils (2.9.1.0.25+) now fully support 16-bit mode (registers and addressing) on i386 PCs. Use .code16 and .code32 to switch between assembly modes. Also, a neat trick used by several people (including the oskit authors) is to force GCC to produce code for 16-bit real mode, using an inline assembly statement asm(.code16\n). GCC will still emit only 32-bit addressing modes, but GAS will insert proper 32-bit prefixes for them. 16bit mode is required for building bootloaders. The question here is, is it possible for Wine to run raw 16bit code when running under a *nix kernel, which typically (always?) run in protected mode? I believe it is not possible without some sort of 16bit emulator/wrapper (e.g., current win16 libs are actually compiled as 32bit). Actually, the modern versions of Windows (Windows95 and up) use 16 to 32 bit 'thunking' which is time consuming and not pretty. It would be nice to get some of the legacy 16 bit applications running under Wine, but this will require a great deal of work and may not be worth the effort. This being said, there is always the one user that has a legacy application which they must have. James McKenzie
Re: NTFS filesystem features - WONTFIX?
Austin English wrote: See http://bugs.winehq.org/show_bug.cgi?id=17938 for background. Sent reply direct to Austin. This may be outside of Wine's control due to flaky NTFS support by some Linux distributions. James McKenzie
Re: implement PS_USERSTYLE handling, tested with Dia(win32)
Hans Breuer wrote:
From b89af7d06fc8cbf5210c61fd58ed62caeddad968 Mon Sep 17 00:00:00 2001
From: Hans Breuer h...@breuer.org
Date: Sun, 29 Mar 2009 18:27:29 +0200
Subject: implement PS_USERSTYLE handling, tested with Dia(win32) - see
http://hans.breuer.org/dia/dia-wine.htm
---
dlls/winex11.drv/pen.c | 31 +++
1 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/dlls/winex11.drv/pen.c b/dlls/winex11.drv/pen.c
index 49fe74c..039798e 100644
--- a/dlls/winex11.drv/pen.c
+++ b/dlls/winex11.drv/pen.c
@@ -54,12 +54,33 @@ HPEN CDECL X11DRV_SelectPen( X11DRV_PDEVICE
*physDev, HPEN hpen )
elp = HeapAlloc( GetProcessHeap(), 0, size );
GetObjectW( hpen, size, elp );
-/* FIXME: add support for user style pens */
logpen.lopnStyle = elp-elpPenStyle;
logpen.lopnWidth.x = elp-elpWidth;
logpen.lopnWidth.y = 0;
logpen.lopnColor = elp-elpColor;
-
+/* support for user style pens */
+if (MAX_DASHLEN elp-elpNumEntries)
+{
+FIXME(PS_USERSTYLE: len(dashes)MAX_DASHLEN %d,%d\n,
elp-elpNumEntries, MAX_DASHLEN);
+physDev-pen.dash_len = 0;
+}
+else
+{
+BOOL overflow = FALSE;
+physDev-pen.dash_len = elp-elpNumEntries;
+for (i = 0; i elp-elpNumEntries; ++i)
+{
+if (elp-elpStyleEntry[i] 255)
+{
+overflow = TRUE; /* can't fit the type */
+physDev-pen.dashes[i] = 255;
+}
+else
+physDev-pen.dashes[i] =
(char)elp-elpStyleEntry[i];
+}
+if (overflow)
+FIXME(PS_USERSTYLE: dashes clipped (type overflow)\n);
+}
HeapFree( GetProcessHeap(), 0, elp );
}
else
@@ -108,14 +129,16 @@ HPEN CDECL X11DRV_SelectPen( X11DRV_PDEVICE
*physDev, HPEN hpen )
memcpy(physDev-pen.dashes, PEN_alternate,
physDev-pen.dash_len);
break;
case PS_USERSTYLE:
-FIXME(PS_USERSTYLE is not supported\n);
+/* handled above */
+break;
/* fall through */
default:
physDev-pen.dash_len = 0;
break;
}
if(physDev-pen.ext physDev-pen.dash_len
-(logpen.lopnStyle PS_STYLE_MASK) != PS_ALTERNATE)
+(logpen.lopnStyle PS_STYLE_MASK) != PS_ALTERNATE
+(logpen.lopnStyle PS_STYLE_MASK) != PS_USERSTYLE)
for(i = 0; i physDev-pen.dash_len; i++)
physDev-pen.dashes[i] *= (physDev-pen.width ?
physDev-pen.width : 1);
This needs a conformance test to show this is what happens in Windows.
If this is not supported in certain versions, you will also need to add
broken() code for those versions with what happens. Look at the Wine
source code and search for the use of this call.
James McKenzie
Re: NTFS filesystem features - WONTFIX?
Kai Blin kai.b...@gmail.com wrote on April 7th: Subject: Re: NTFS filesystem features - WONTFIX? On Tuesday 07 April 2009 04:21:37 Vitaliy Margolen wrote: - Implement missing functionality - will most likely be nearly impossible without driver support for special features. Or have to be emulated by Wine (then why not for any other FS?) We can probably get away with 80% of the apps only using 20% of the features, as usual. I guess that apps are mostly interested in ACLs, which could be mapped to POSIX acls, stored in file attributes or some database or simply faked. Samba does this, I don't see why we couldn't. Can we use Samba code in Wine to make this a reality? James McKenzie
Re: winequartz.drv Mac OS X UI discontinued?
Adam Strzelecki wrote: I googled a bit more. There are at least two ways of achieving this mentioned in the docs of libFoundation: by using XML-RPC call and by wrapping classes in ANSI-C APIs. [4] Well actually you can easily access all Obj-C features trough the following pure C API: http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html While the above is correct, modern Cocoa, in opposite to it's precedessor NeXTstep/OpenStep, is based on Quartz and CoreFoundation, both of which are plain C APIs. There's no need for neither Carbon nor Cocoa nor Objective-C to get some basic graphics to the Mac OS X screen. You are right, however what we all want to have is probably some Wine seamless integration with OSX GUI at higher level than Quartz which is just equivalent of WinGDI, and for this you need to somehow use HIToolkit of Carbon extra to do windows management, font handling etc. for example: http://developer.apple.com/documentation/Carbon/Reference/Window_Manager/Reference/reference.html#/ /apple_ref/c/func/CreateNewWindow .. to create new window. The problem here is that HIToolkit from Carbon is a bit pushed away by Apple in favor of Cocoa, and the reason is that Carbon has its roots in Mac OS 8, and Cocoa is the new API for Mac OS X NextStep based system, moreover there's no 64-bit HIToolkit (which doesn't matter for Wine now, but may matter in the future). There's nice discussion here: http://www.lazarus.freepascal.org/index.php?name=PNphpBB2file=printviewt=5017start=15 I believe if pure C source is a constraint for Wine, one should try to make winequartz.drv to be Quartz API for all WinGDI like stuff + some HIToolbox for Window management and CoreText for text display. Regards, What is the status of work on this project? James McKenzie
Re: implement PS_USERSTYLE handling, tested with Dia(win32)
Hans Breuer wrote: At 05.04.2009 23:54, James McKenzie wrote: Hans Breuer wrote: From b89af7d06fc8cbf5210c61fd58ed62caeddad968 Mon Sep 17 00:00:00 2001 From: Hans Breuer h...@breuer.org Date: Sun, 29 Mar 2009 18:27:29 +0200 Subject: implement PS_USERSTYLE handling, tested with Dia(win32) - see http://hans.breuer.org/dia/dia-wine.htm --- dlls/winex11.drv/pen.c | 31 +++ 1 files changed, 27 insertions(+), 4 deletions(-) [...] This needs a conformance test to show this is what happens in Windows. If this is not supported in certain versions, you will also need to add broken() code for those versions with what happens. Look at the Wine source code and search for the use of this call. The only broken() calls I found are in */test/*. If I understood correctly for PS_USERSTYLE and ExtCreatePen these tests are allready there, see: dlls/gdi32/tests/pen.c And they are un-effected by my patch, which is not changing any API behaviour, but just fixes the implementation to finally match the API. Do they correct implementations to match Windows behavior and do tests exist for Wine that demonstrate this (the tests may be marked to_do wine and this marking needs to be removed.) If behavior is not implemented in a particular version of Windows or differs then the test needs to be marked as broken, which by your comments I will assume is already in place and correct. Thank you for fixing this as there are many areas where Wine is lacking in proper implementation and hacks and code workarounds exist at the present time. Or am I still missing something? No, you are not. It has been a very long week this week. I'm recovering, still, from the flu and other problems. If I've offended you, my apologies. James McKenzie
Re: Re : [4/4] (Try4) msi/tests: Fix package test when run on root drive directory.
Nicolas Le Cam wrote: 2009/4/11 Ben Klein shackl...@gmail.com: 2009/4/11 Nicolas Le Cam niko.le...@gmail.com: 2009/4/11 James Hawkins trui...@gmail.com: Let met explain : Running test on wine in folder C:\test : works (expected C:\test got C:\test) Running test on wine in folder C:\ : works (expected C:\ got C:\) Running test on wine in folder Z:\home\nlecam\Projects\wine\wine-git\dlls\msi\tests : works (expected Z:\home\nlecam\Projects\wine\wine-git\dlls\msi\tests got Z:\home\nlecam\Projects\wine\wine-git\dlls\msi\tests) Running test on Windows in folder C:\test : works (expected C:\test got C:\test) Running test on Windows in folder C:\ : fails (expected C:\ got ) This looks to me like it would be dependent on the WAY you run the test. Running test on Windows in folder X:\Documents And Settings\nlecam\Desktop : fails (expected X:\Documents And Settings\nlecam\Desktop got C:\Documents And Settings\nlecam\Desktop) This looks like X: is mapped to the same place as C:, and wine's path translation is picking C: first. If that's so, it would also depend on the way you run the test. Of course, I could be astronomically wrong :D Hi Ben, Tests were launched from cmd.exe, current directory was where executable resides. Those results (blank and X: becomming C:) were from Windows not Wine. X: is a network drive. I admit I should do more tests, at least : * launch test from a real drive other than C:\ * launch test from another directory than where executable resides. * install Windows on another drive than C:\, with or without a C:\ drive, to see if it's really SystemDrive that msi takes or just the first drive it can find. Nicolas: You should also test the cases that are failing from within Wine as well. We do have the capability to map to a X: drive by mapping a network drive to this letter as well. It appears that C:\ is not returning a proper value either from Windows (which would not surprise me) or that Wine is not functioning the same as Windows in this case. You cannot mark this 'todo_wine' the code has to be fixed or the test has to be fixed. James McKenzie
Re: Setting working directories for applications?
Igor Tarasov wrote: Hi Jeff There is Wine's start.exe which takes a /Unix option to start the supplied file in unix path form, which both sets the working directory and provides the commandline double quoting quirk which Windows Explorer does. So, instead of cd ~/.wine/drive_c/foo wine bar.exe, you can wine start /Unix ~/.wine/drive_c/foo/bar.exe Well, I've already have looked into start.exe, and it does not provide functionality I need. Look: we have some program, prog.exe It is located it ~/.wine/drive_c/foo/ . But it needs it's working dir to be set to ~/.wine/drive_c/foo/bar. So, from terminal you can launch it this way: cd ~/.wine/drive_c/foo/bar wine ../prog.exe Start.exe won't help here, as I don't see any path-related options there. When installing such application, wine woul convert .lnk into .desktop that look like this (irrelevant options skipped): [Desktop Entry] Name=Da Prog Exec[$e]=env WINEPREFIX=/home/user/.wine-wt wine C:\\foo\\prog.exe Path[$e]=$HOME/.wine/dosdevices/c:/foo/bar XFCE ignores Path attribute, and prog.exe won't launch or would complain it can't find some files and needs to be reinstalled. Mac also have some problems with this. BTW, according to freedesktop specification Path attribute is optional. http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html The problem is that you are technically working in Windows and the working directory may need to be set in the registry. Please look at this in a working Windows configuration. I have found in these cases that using regedit and duplicating the setup does tend to work. And the fact that you are using a Mac does not have anything to do with this situation, it is a 'broken' feature of Windows that Wine has to reproduce properly. James McKenzie
Re: do ERR messages imply bugs?
Vitaliy Margolen wrote: chris ahrendt wrote: 17997 Gecko is installed and reran test... same result... valid bug 17998 is the locking issue... and it occurs not just in the rest but in another application as well.. What errors? What exactly isn't working for you? You have failed to explain that. Until you meaningfully can explain everyone what isn't working for you? What exact applications are you having problems with? Where are they failed tests you are speaking of, these bugs invalid! This is why I don't like the current configuration of Bugzilla and how we pass information along. Bugzilla should request an application name and AppDB entry number. We need to make folks 'smart' about why ERR messages appear and what is different from FIXMEs. We also need to improve what is in ERR messages as we can provide fix information as well. James McKenzie
Re: do ERR messages imply bugs?
David Gerard wrote: 2009/4/12 James McKenzie jjmckenzi...@earthlink.net: Bugzilla should request an application name and AppDB entry number. Demanding an appID number will certainly keep the bug reports down, though at the expense of bug reporting. The idea is that not all users look into Bugzilla to see if there is a problem and a workaround. They sometimes look into the Applications Database. If we link bugs to applications this makes it easier and then if we link bug status back to the applications database that lets folks know the status of a bug and if it is fixed or not (there are such things as regressions.) I can't see making bug reports arbitrarily more difficult as a good way for devs to get an idea of what's broken. I understand your concern. I like bug reports, I just don't like bug reports in a vacuum. If we can get some of the functionality of an automatic Bugzilla to Applications Database linker in place this would make it much easier to avoid (not prevent) duplicate reports and for bug reports to have application entries and the other way round. I really would like to see a bug report for each garbage entry in the Applications Database with associated terminal output and such. This might give developers a push to fix a problem or implement code based upon the number of related problem reports and affected programs. For example, if only three people report the same bug on the same program would it make more sense to work on a problem that has fifty reports/votes and it affects a dozen programs. Of course, implementing the linker may be a project in itself. James McKenzie
Re: do ERR messages imply bugs?
Vincent Povirk wrote: On Sun, Apr 12, 2009 at 3:05 PM, Vitaliy Margolen wine-de...@kievinfo.com wrote: Ok, but my point is (and I'm not saying we should necessarily do this), according to the Wine Developer's Guide an err is something that we should be concerned about, by definition. If we buy this, and some current err messages are often harmless, implying no loss of important functionality, they should be changed to some other channel. +1. If the report is not an error which will cause problems then it should be something else, like a Warning that your program may not function in the way you expect or a fixme, with a note that the requested function is not implemented. There are way to many error messages that are causing concerns with our users. James McKenzie
Re: do ERR messages imply bugs?
Ben Klein wrote: 2009/4/13 chris ahrendt celtich...@aol.com: Vincent Povirk wrote: On Sun, Apr 12, 2009 at 5:24 PM, Ben Klein shackl...@gmail.com wrote: 2009/4/13 Vincent Povirk madewokherd+8...@gmail.com: But the description doesn't say invalid conditions. It says serious errors in Wine. That's something that should never happen in tests, as it would imply that the state of the libraries we're testing (and thus the test) is invalid. How about serious errors in Wine, or in the test cases, sometimes deliberate errors in the tests? As Vitaliy points out, some tests deliberately do invalid things to make sure they fail. We can't ONLY test on things that succeed! I'm not against changing the description. If it's OK to have err messages for cases that we know fail (but don't crash or prevent the library from continuing to function), then the Developer's Guide is wrong and should be changed. I also don't care how long it takes to make the change, as long as there's a consensus that it's the guide that's wrong and not the reality of what's in Wine. This is EXACTLY the point I am trying to get to.. if they are normal and not ERRORS but warnings then they should be thus and noted in the developers guide. Right now Wine isn't even following its own guidelines in this case. No. Not warnings. Errors. They are errors. There is no way to distinguish an error caused by a real application from an error caused by a Wine test. If the situation is an error and it is expected, the test should handle this, like: ok (some_test_here_that_should_fail, The test that should fail, did/n) I'm guessing that most of the tests that should fail, do. I don't know if there is a failure like there is an ok. If you don't like it, run all your tests with WINEDEBUG=-all. And that will prove nothing. Tests should be run with debugging on. You are really being sarcastic, right? As to the discussion, I will add my .02 Eurocent here: Fixme: Code that is not implemented that should be. Warning: Code that encountered an unexpected or new condition that is not normal. Data should not be corrupted by this event. Error: Code encountered a condition that will result in corruption of data. It appears that we have 'error creep' and that is not good from a user point of view and it is really irritating from a support point of view. During testing an error could be either a Warning or an Error. Tests should not be run against non-existent Wine code, but should against existing Windows code. The situation with testing is that unexpected or improper behavior of code should be an error. There is no such thing as a warning during a test run. Either the test passes, which means that Wine is acting the same as a certain version of Windows, or it is not. Now, the problem is that we are sending cryptic messages to end users, most of which they can and should ignore. Err messages piling up on their terminal windows should be a cause for concern. If we know that a condition does not cause data corruption, then we should not be marking it as an error, but maybe a warning or if the code is non-existent or improper, a fixme. Can we start to clean up some of the most obvious it is not an error but the message says it is so that we can calm down users who encounter them? James McKenzie
Re: do ERR messages imply bugs?
Vitaliy Margolen wrote: chris ahrendt wrote: Vitaliy Margolen wrote: chris ahrendt wrote: 17997 Gecko is installed and reran test... same result... valid bug 17998 is the locking issue... and it occurs not just in the rest but in another application as well.. What errors? What exactly isn't working for you? You have failed to explain that. Until you meaningfully can explain everyone what isn't working for you? What exact applications are you having problems with? Where are they failed tests you are speaking of, these bugs invalid! DO NOT REOPEN THEM! Vitaliy. THe ERR mesages which are in the logs I uloaded. As pointed out in the wine development logs an ERR is only supposed to happen if something goes wrong or is not working correctly. So either these are warning messages and need to be changed as such or they are actual failures in the underlying code and will need to get fixed. If the action is normal for the failure in the test case then it should be output on the screen somewhere in the log stating this is normal. You wrong. As I said, tests are _allowed_ and some really _supposed to_ test invalid cases. Where Wine 100% correct about complaining. But the goal of each test is either succeed or fail. If it succeeds then there is no bug. Conversely, if a good test starts to fail or error messages appear where there were none, we have a problem that needs to be reported so it can be fixed (this happened with Wine 1.1.18). Again there are not failures in the tests your ran! There is nothing to fix here. Move along don't waste everyone time for something YOU DO NOT LIKE! Or send patches. The problem is that error messages should not appear where there are no errors. They should be either warnings or fixmes. If the test passes but a bunch of error messages appear during the test run, there is a coding problem that needs to be fixed. This is why we are answering user questions with 'The error message can be ignored, there is nothing wrong with the execution of your program.' This makes it appear that the developers don't know what they are doing and that makes the overall project appear bad. Conversation is over. DO NOT WASTE everyone's time!!! We are not 'wasting time.' This issue needs to be addressed by the development community so that errors, warnings and fixmes are properly reported. We can and maybe should get more granular when we work with code. Maybe a fixme for a known but unimplemented function and a warning for an incomplete function. Maybe changing the wording on an error message that really is an error in code but will not cause a program to crash. I've seen error messages that really should be fixmes and the other way around where a fixme causes some programs to terminate with a screen full of debugging code. James McKenzie Vitaliy
Re: Re : [4/4] (Try4) msi/tests: Fix package test when run on root drive directory.
Nicolas Le Cam wrote: 2009/4/13 James McKenzie jjmckenzi...@earthlink.net: Nicolas Le Cam wrote: James, Here are updated patches for part 3 4 of my previous patch set. Tell me if you think I could submit them to wine-patches. For patch 3, the only todo_wine is when launched from root drive dir as explained in my previous mail. For patch 4, I skip a test if test is executed on root drive dir, as it doesn't make sense to execute it in this case. If needed I can remove the skip and change expected value to be first fixed drive when test is run on root drive dir. But this is already tested by patch 3 (when run on a root drive dir). Did these work with WindowsXP or Windows Vista as expected? I don't have them here to test, only Wine. I would defer the todo_wine to others with more experience, as this marks the tested function needs more work with Wine and my experience with msi is only as a user. James McKenzie It worked as expected on Win2k and Wine. I can test it on WinXP if wanted, but I don't own any Vista. I would try it on XP as that is the default Windows we try to reproduce now. The todo_wine is to handle root drive directories where Windows output first fixed drive where Wine currently output an empty string as demonstrated on . Yep, that I do know about. Fix seems to be simple. We just need to break the for loop after the GetDriveType test in ACTION_SearchDirectory function in appseach.c if path is only three characters long (attr should also be checked against INVALID_FILE_ATTRIBUTES just after it). Simple fixes always turn out to be the most complex whenever I've dealt with them. ACTION_CheckDirectory could perhaps be updated to handle root drive directories too, but I'm not certain with this one. I agree. I don't know of any software package that should be installed to any root drive that would be handled by msi. As I don't have any experience with msi at all even as user, I will certainly wait for someone to validate what I'm saying. I do have experience using msi as the installer. In my experience, no program installed by me was to a root directory. However, some programs installed were run from the D:\ and C:\. So, it may be a good idea to insure that Wine's msi can handle these cases. Thanks for review You are welcome. I hope that the root directory case can be corrected as well. James McKenzie
Re: Setting working directories for applications?
Damjan Jovanovic damjan@gmail.com wrote on April 14th: On Sun, Apr 12, 2009 at 8:29 AM, Igor Tarasov tarasov.i...@gmail.com wrote: Do our .desktop files even work on Mac? I don't think the Aqua specification allows for .desktop files, but .lnk files are connected to the Winehelper application and they do work. If the .desktop files require a specific launcher, it may be possible to get them to work on a Mac. James McKenzie
Re: [PATCH 2/4] gdi32: fetch child fonts by real parent font name
Paul TBBle Hampson wrote: This patch fixes bug 18044. Basically, the built-in FontLink functionality for subsituting alternative fonts where a certain font is missing glyphs (used by default for Tahoma and Microsoft Sans Serif under Windows) doesn't work if the font is loaded via a FontSubstitution entry. The only place this is really likely to happen turns out to be using MS Shell Dlg as a font name, which is generally discouraged for general UI use (as far as I can tell, you're supposed to use a lookup function which normally returns Tahoma or Microsoft Sans Serif directly) but this happens to be the case for uTorrent 1.8 onwards. Paul: Where is the patch? I could not find it. James McKenzie
Re: Janitor: list.h functions defined but not used
Glenn L. McGrath wrote: Hi all, im new to the list, im interested in grinding away at some of the warnings wine generates... make depend was complaining about some static inline functions that it thinks arent used, this patch uses __attribute__ ((used)) to disable the warning. Glenn Glenn: What compiler was complaining about the static inline problem? Your solution may cause problems with other compilers. James McKenzie
Re: include: Define IN6ADDR_ANY_INIT and IN6ADDR_LOOPBACK_INIT and code for IN6_IS_ADDR_LOOPBACK
Jeff Latimer wrote: Jeff Latimer wrote: This patch enables putty to compile and run using IPv6. I meant to say that André Hentschel was doing the hard work with putty and merely ask me to do this little bit. Jeff Thank you for doing the heavy lifting to all who are working on this. James McKenzie
Re: [1/7] [wined3d] add ps_np2fixup_t ptr to shader_arb_priv (review)
Tobias Jakobi wrote: For review: This patchset implements np2 texcoord fixup in ARB mode. Constants used to store texture dimensions are already packed, using the same data structures like the GLSL packing code. The code is finished and works quite well. It has been tested with Max Payne 2, HL2 and FEAR. All games now work with post-processing effects and anything else that needs NP2 textures on the nvidia FX series. Greets, Tobias Tobias: Do you plan on rewriting this to work in the backend? James McKenzie
Re: Wine fundraising idea
Austin English austinengl...@gmail.com Sent: May 1, 2009 12:39 PM To: Wine Devel wine-devel@winehq.org Subject: Wine fundraising idea Howdy, +1 James McKenzie
Re: error report
Ruben Hillewaere wrote: Hello, I wanted to install (Dar)wine on my Intel Mac, first I've tried with the binaries found on http://wiki.winehq.org/MacOSX/Installing The installation goes fine, but running any of the apps fails. So, instead, I've tried to build Wine from Scratch, this is what I get: ru...@cakeslicer:~/distrib$ ./create_darwine_distrib.sh $VERSION ~/Desktop/wine-$VERSION # Packaging Darwine for version 1.1.20 using Wine sources in /Users/ruben/Desktop/wine-1.1.20... # Building Wine in /Users/ruben/Desktop/wine-1.1.20 (warning: takes a long time)... configure: WARNING: mach-o/dyld_images.h: present but cannot be compiled configure: WARNING: mach-o/dyld_images.h: check for missing prerequisite headers? configure: WARNING: mach-o/dyld_images.h: see the Autoconf documentation configure: WARNING: mach-o/dyld_images.h: section Present But Cannot Be Compiled configure: WARNING: mach-o/dyld_images.h: proceeding with the preprocessor's result configure: WARNING: mach-o/dyld_images.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to wine-devel@winehq.org ## configure: WARNING: ## ## configure: error: FreeType development files not found. Fonts will not be built. Use the --without-freetype option if you really want this. * Error: Can't build wine Did you install XCode, the X11SDK from your Leopard disk, and get the required packages from either Fink or MacPorts? You might want to try either: 1. The build environment from Mike Kronenberg's site (it is on the same line as the unstable version), or 2. Install either Fink or MacPorts and use their build system. Either should give you a working Wine for MacOSX. If you have further comments/questions, we are here to help. James McKenzie
Re: Severity levels
Ken Sharp wrote: Nicklas Börjesson wrote: I think that the users should have quite a say with regards to how important a bug is, because for every user putting in the (considerable for a user) effort of reporting a bug, there are dozens that don't say anything at all. To every Wine user, their application not working is critical. This is clear by all the bugs that are logged incorrectly every day, because nobody bothered reading the FAQ. You bet. The application that I reported, which has a perfectly good Linux port, has to be fixed absolutely last week. I've seen this in the user list again and again. It gets boorish after a while. Let's try user education. You only get to choose normal and we get to up/downgrade until you can prove that you know how to do it right. This is how some companies do it. James McKenzie
Re: Severity levels
Ben Klein wrote on May 4th: Final post from me. 2009/5/5 Nicklas Börjesson nicklas.borjes...@ws.se: b) I thought that priority was developer priority and severity was severity for the users. Nope. Both for the benefit of developers, hence why they're both on bugzilla. One question: Does Bugzilla have a place for user's to place the Impact on their ability to use a Windows program? This is much different than the priority and severity fields. James McKenzie
Re: Severity levels
Darragh Bailey wrote on May 5th: On Mon, May 04, 2009 at 11:24:58AM -0700, James Mckenzie wrote: Ben Klein wrote on May 4th: Final post from me. 2009/5/5 Nicklas Börjesson nicklas.borjes...@ws.se: b) I thought that priority was developer priority and severity was severity for the users. Nope. Both for the benefit of developers, hence why they're both on bugzilla. One question: Does Bugzilla have a place for user's to place the Impact on their ability to use a Windows program? This is much different than the priority and severity fields. James McKenzie In catching up on this long discussion, this is the first post that I've seen that actually comes close to pin-pointing what is being requested. Current: Severity = messure of bug impact on wine Requested: Severity = message of bug impact on application running in wine IMHO the bugzilla severity field is not the right place to measure impact to other applications of bugs in the current development. Attempting to track that type of information in the severity field will always lead to confusion and problems. As a reminder, Bugzilla is for developers to work in user discovered issues. The Severity field, as it is, is correct for developer/triage evaluation of discovered issues. It should not be changed. However, a developer should be aware of the impact on the user experience and the user's determined severity of a problem. Users should not be determining this through the use of the severity and priority fields. I have discussed the use of an impact field to have the user state what impact the problem has on their ability to use/install a particular application. Some problems have a more severe impact on certain applications. The use of metabugs to follow what applications are affected is HIGHLY discouraged. The users of Wine should be able to state, in one place, what the bug is, what its impact to them is and the status of repair and/or workaround(s) for the bug is. The Applications Database is the location where a user can input what they found through use of Wine by Linux/UNIX version/distribution and Wine version. Bug reports should reside in Bugzilla and users should be able to input bug reports quickly (10 minutes for a non-English speaking user.) This seems to not be happening at the present time and users are confused by the Bugzilla interface and fields presented to them. We should not rely on the ability for users to read and understand what field does what but only present to them fields needed to be filled out by users when they submit a bug report. Since the severity and priority fields are developer only, they should not be present. The proposed impact field should be a drop down list only and present common impacts encountered by users, such as Unable to Install Application, Unable to run application,Screen is unreadable,Text not appearing on screen,Graphics are garbled. This allows the user to provide input and allow the triage team to provide feedback to the user as well as assign appropriate severity and priorities to bug reports. Please advise if this is what the project desires to do. Again, this is to improve the user experience for the unexperienced (nOOb) Wine user. Experienced users do not have these difficulties but this takes time away from developers and triage teams to provide user education. James McKenzie
Re: Severity levels
IneedAname wrote: Wine does have meta bugs look at the application data base. Each application has a list of bugs that effect that program. I think that you missed what a meta-bug is in the Bugzilla sense. A meta-bug would collect all of the applications affected by a particular problem, we do that by adding them to the comments area and closing out the duplicates. Why Wine does not use meta bugs in bugzilla is because they end up being Make my all programs work with wine! Now list. Either that, or they get abused by folks adding bugs that have NOTHING to do with the original bug. In any case, meta-bugs are not allowed in Bugzilla, period. James McKenzie
Re: DIB Engine : Almost 100% working
Massimo Del Fedele wrote: Warren Dumortier ha scritto: 2009/5/10 Massimo Del Fedele m...@veneto.com: Massimo Del Fedele ha scritto: Well, after some (many) bugfixes and additions, the mighty DIB Engine is almost 100% operational. On one of tested apps (MSN Messenger) it behaves even better than original one :-) For whom wish to test it, bug 421 page. Ciao Max fixed also last (hopefully) color format error, now some games, also D3D and Opengl ones work perfectly. Ciao Max Which games are concerned? Also eMule here is slow when the window is resized, would this DIB engine fix that or am i wrong? Well, I'm not a big game player, so I don't know how many games would benefit of it. Max: Good work. Have you started to think about how to get this into Wine where AJ will approve? James McKenzie
Re: Add tests for DirectDraw surface reference counting
Luke Benstead wrote: 2009/5/15 Stefan Dösinger stefandoesin...@gmx.at: Am Freitag, 15. Mai 2009 13:52:23 schrieb Luke Benstead: Reference counts are wrong in Wine which causes some games to fail. I'm working patches to make these tests pass so we can remove the todo_wine's. Luke. The patch adds trailing whitespeaces in a few lines. Please remove them. Otherwise the code looks good to me. Oops, same patch without the trailing whitespace. Send it to wine-patches as (try 2) with a comment about removing the white spaces :) James McKenzie
Re: comdlg32: Optimize german Find and FindReplace Dialog(try2)
Dawncrow: Your fix does not match what is displayed in W2K. What does this dialog look like in WindowsXP? James McKenzie -Original Message- From: Dawncrow webmas...@dawncrow.de Sent: May 15, 2009 11:14 AM To: wine-patches wine-patc...@winehq.org Subject: comdlg32: Optimize german Find and FindReplace Dialog(try2) compare can be found here: http://www.dritimage.de/uploads/bilder/124241122145_comdlg32winepatch.jpeg --- dlls/comdlg32/cdlg_De.rc | 14 +++--- 1 files changed, 7 insertions(+), 7 deletions(-)
News on Wine 1.1.21/MacOSX/XQuartz 2.3.3
The news is good. First, if you are using Tiger, X11 is still broken and probably will remain so. Second, you do not need to upgrade to Leopard 10.5.7 to use XQuartz 2.3.3, the installer was fixed so it would install on 10.5.6. Third, Graphical games that depend on GLSL functions work. I tried dOOm, the Windows95 version, and it is definitely playable. Frame rates drop whenever you pick something up, but this also happens with CrossOver Games for Mac. This does not happen with Crossover Pro for Mac 7.1. I do not have any other programs that depend on GLSL functionality, but I suspect they will work on this combination. BTW, the version of Wine for Mac that I used for testing was built using Mike Kronenberg's Build Environment 1.1.5. James McKenzie
Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3
Austin English wrote: On Sun, May 17, 2009 at 6:49 AM, Steven Edwards sedwa...@bordeauxgroup.com wrote: On Sat, May 16, 2009 at 11:23 PM, James McKenzie jjmckenzi...@earthlink.net wrote: BTW, the version of Wine for Mac that I used for testing was built using Mike Kronenberg's Build Environment 1.1.5. I tested this last night myself and am running winetest now. I still get a few d3d texture failures but that could be because my mini's a POS with the Intel GMA card. I'm interested in seeing other results so if you get a chance could you (or anyone else lurking with OS X) do a winetest run? Ideally, against a more recent wine version. Shameless plug: I've got a script to do it, but no one that I know of is testing it on OS X. If someone could test it, I'll add any needed fixes: http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh Austin: Contact Mike Kronenberg or Zach Drayer and see what they currently have. I know that Mike's builds add all of the necessary libraries to the Application Object. That keeps the system clean and allows for 'Drag and Drop' installation/removal of Wine for MacOSX. Your script seems to be clean as well, but has no MacOSX functionality added to it. Would be nice if it were there. James McKenzie
Re: [Article] WINE and the importance of application compatibility
Scott Ritchie wrote: nn wrote: WINE and the importance of application compatibility http://community.zdnet.co.uk/blog/0,100567,10012751o-2000630136b,00.htm It's a good article, though it's sad to see a mention of WineX as a serious alternative to Wine. WineX was obsolete years ago (and the consensus about its successor Cedega on the various web forums seems to be that it's often substantially behind Crossover Games). The article stated that most of it was a few years old. Codeweavers, you need to do a better job letting people know Crossover Games exists. WE need to get to the point where most of the common business type applications will run in Wine without a bunch of twiddling and fixes. The average Joe user will not put up with this. I've been on this mantra for a long time. Build a better mousetrap built on an OS that is more robust and market it correctly and you will have the world at your fingertips. Witness the comparision between Windows and OS/2. OS/2 was technically superior but had problems running most of the current software. It 'died' and Windows lived on. The same could be said about Linux/Wine at its current state. I need Wine to run a few Windows applications, one of which will not be made for either Linux or Mac. Thus, I have to have Windows compatibility or Windows itself. I don't feel like 'polluting' my system, so I need API compatibilty. Wine delivers this for me. The problem is that I need another Windows program to run. I'm going to work on it and report bugs as they occur. I may also start running Winetest to see what works and what does not. Hopefully, with the recent release of XQuartz 2.3.3, most of the problems have gone away. James McKenzie Thanks, Scott Ritchie
Re: [Article] WINE and the importance of application compatibility
Steven Edwards wrote: On Sun, May 17, 2009 at 8:09 PM, Dan Kegel d...@kegel.com wrote: Sure would be nice if we could convince the DoD they needed a second source for Windows :-) Maybe a big customer like the DoD would help but I am starting to doubt it. The situation I face with my day job, is that we can't even get support for certain applications in VMware. As soon as we say we have a virtualized cluster they balk. And we are talking about situations where we are spending millions of dollars on our software and are going to be supporting it in house. With that sort of reaction, it leads me to think we are never going to make major inroads except for the end users at home or the people buying Linux netbooks. Stephen: Many companies don't trust Open Source. They just don't have the assets to do a proper code sweep and to see that we do not want to swipe their secrets, but give them something better. Of course, we all know the outcome of the Windows versus OS/2 wars: Windows won and the best product went home (it is still available by the way.) James McKenzie
Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3
Roderick Colenbrander wrote about Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3 On Wed, May 20, 2009 at 4:04 PM, Austin English austinengl...@gmail.com wrote: On Wed, May 20, 2009 at 4:46 AM, Roderick Colenbrander thunderbir...@gmail.com wrote: On Tue, May 19, 2009 at 6:41 PM, Mike Kronenberg mike.kronenb...@kronenberg.org wrote: On 18.05.2009, at 06:56, Dmitry Timoshkov wrote: James McKenzie jjmckenzi...@earthlink.net wrote: Austin: Contact Mike Kronenberg or Zach Drayer and see what they currently have. IMHO since they haven't even bothered so far to change the license from GPL to LGPL to match Wine, and clarify what exactly is so much different in their builds so that they insist on different naming (Darwine vs. Wine), they shouldn't be even considered as partners to the Wine project. If we could have our own Wine builds for Intel Macs, that would finally help to avoid this confusion Darwine adds, and remove it from our Wiki altogether (since it's apparently where the users coming to them from). -- Dmitry. Hi, (I hope I did not double-post, but somehow my mail from yesterday was eaten by filter-gnomes) It's not about being willing to, but plain lack of time. I follow this list closely and work on solutions as time permits. After half a year, it's been four weeks now that I am able again to build and test on a regular base again. There are other components on OS X that need some love, like the winehelper.app into which I'm looking atm. License and renaming is definitely on the list. I thought to revamp the package, once the winehelper is replaced, to not double do the work. As already mentioned, I build the dependencies and store them inside the apple .app package, which allows for drag'n'drop installation and removal. Having the dependencies as frameworks would be even better, as there is a lot of trouble with PATHS, especially if multiple environments are on the system, like fink and macports. But if the name-change is the most pressing issue, I will gladly do that with this weekends release. Mike Kronenberg Could you also upload some docs / scripts on how to build 'DarWine' from scratch? I have an app which I need to run on osx which I like to package as well. I have time to help fixing osx issues (duplicating the effort is not worth it). Roderick It's available under 'build env': http://www.kronenberg.org/darwine/buildenv-1.1.5.zip -- -Austin Thanks, I used this to compile wine 1.1.21 for testing purposes this week. I had to update the scripts a bit (e.g. use newere versions of some libraries and tools because the old ones are offline). I can post a patch against the old script. Further don't ship the opengl hack anymore for new wine packages as you are aware it isn't needed for xquartz 2.3.3 anymore. Everyone should move to the latest xquartz. This might prevent some opengl bug reports which I have to close on bugzilla as well ;) Does XQuartz 2.3.3 apply on Tiger systems? The 'hack' is for both Tiger and Leopard so that some missing functions will work. Please list the updated libraries so that I can upgrade the script as well. James McKenzie
Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3
Roderick Colenbrander wrote: Thanks, I used this to compile wine 1.1.21 for testing purposes this week. I had to update the scripts a bit (e.g. use newere versions of some libraries and tools because the old ones are offline). I can post a patch against the old script. Further don't ship the opengl hack anymore for new wine packages as you are aware it isn't needed for xquartz 2.3.3 anymore. Everyone should move to the latest xquartz. This might prevent some opengl bug reports which I have to close on bugzilla as well ;) Can you provide the updates to the scripts? Since I am using Leopard, the opengl fix is not needed anymore, but it may have to stay until XQuartz 2.3.3 is backported for Tiger. James McKenzie
Re: DIB Engine : passing all tests
Steven Edwards wrote: On Sun, May 24, 2009 at 11:06 AM, Massimo Del Fedele m...@veneto.com wrote: André Hentschel ha scritto: No idea on what will happen with Mac or other unixes I am attempting a Mac build now. As with the rest of the discussion, It would be nice if we could produce a PE version using something like cygwin with X11 headers and the -mno-cygwin switch but I don't know if this would really work. If did then it should work on everything. Let me know how this goes. I'm interested in improvements that will help all *nixes, including MacOSX. James McKenzie
Re: DIB Engine : passing all tests
Steven Edwards wrote: On Sun, May 24, 2009 at 9:23 PM, James McKenzie jjmckenzi...@earthlink.net wrote: Let me know how this goes. I'm interested in improvements that will help all *nixes, including MacOSX. I think I am using the latest patch, its dibeng_max.zip thats got the 1-10 patches. There are some major graphical glitches, though it could be related to me having Quartz Extreme and Quartz2d enabled on unsupported hardware. It does seem much faster though. Sorry I don't have time right now to do a complete report. I'll try to upload information to bugzilla in the morning after I make my environment a little more sane. That's ugly. Did you attempt to type in something in the Document area? I don't have the time tonight to attempt to build and run the DIB stuff to see what it does to the games and other programs that I work with. Maybe, tomorrow afternoon after my bicycle ride. James McKenzie
Re: DIB Engine : passing all tests
Paul Vriens wrote: Massimo Del Fedele wrote: The engine has still some known bugs (known by me :-) ) which are not spotter by wine testsuite, mostly related to coordinate spaces in xxxBlt functions. Are they not spotted because the tests don't cover these? If so, would you be able/willing to add some tests to the test suite? Paul: Max knows about the problems and the tests. He just does not have the time right now to fix the problems and write the tests. He has hinted and asked others to help him. I have no knowledge of the DIB engine nor its processes, but I'd be willing to give it a go on the Mac, but I don't have any programs that appear to use the functions. James McKenzie
Re: Does wine handle virtual midi ports correct on OSX?
Emmanuel Maillard wrote: Does notes play well when playing ? Correct duration, correct tempo or other kind of timing issue ? Have you see fixme about MOD_MIDIPORT in log ? Emmanuel: Pardon my barging into this conversation, but music does not play correctly with Doom. Not the CD Music, but the background music. I get no error messages in the log file either about MOD_MIDIPORT. MacOSX 10.5.7 James McKenzie
Re: /. wants a fork
Nicklas Börjesson wrote:
Not sure, but I see the second time around was a success for him.
Let's not look to hard.
He (or her) does have the right to having an opinion and going out of one's
way finding out and posting here would only appear vindictive and fuel
interest.
1. I don't feel like creating a /. account just to reply.
2. AJ has keep several bad patches from being applied to Wine since
I've been here. Without this, we would have a project that supports a
couple of programs real well and others would be complete garbage..
3. There should be a code style and submission guidance document.
Something that explains coding style (four spaces vice tabs) and comment
style ('c' style vice C++/VC++/Java). It would also be nice to have a
statement that a patch has to affect one and only one area or bug. Oh,
fixes CANNOT break existing running programs, just to get your favorite
running, if you want them accepted.
Now with that being said, getting the DIB engine into Wine may take a
lot of shoehorning and for AJ to look over all of the code and
accept/reject it with good notes and reasons. You can do better is
not, in my book, a good reason. Your code is not up to our standards
is with a side comment of look at what is accepted and what is
peer-rejected before resubmission. Of course, AJ does take on projects
that a coder just cannot make work within the standards. And this is a
good thing. Sadly, Electroshock decided that he would take his toys and
go play in another sandbox.
And lastly, I think there is a site at repo.cz that has all of the
unaccepted Wine code somewhere, that we all could look at and fix.
James McKenzie
Re: wined3d: {Name of patch here}
Pavel: Just as a hint, can you name your patches to be more descriptive. I am looking for a fix to this problem, and will attempt to test this against DooM to see if the slowness problem I have is fixed. Thank you for contributing to the Wine Project. James McKenzie -Original Message- From: Pavel Prochazka proch...@inf.upol.cz Sent: May 27, 2009 5:40 AM To: wine-patc...@winehq.org Subject: wined3d:
Re: DIB Engine : passing all tests
Massimo Del Fedele wrote: Alexandre Julliard ha scritto: The last time I rejected a simple patch from Massimo, he basically said that he didn't have time to fix the patch and just dropped it. That doesn't encourage me to spend more effort on reviewing his more complex stuff. Hi again :-) Well, to be precise those were some patches rejected, one with some explanation and others not. Former was about adding page size support to wineps.drv. I haven't dropped it, but you told me that an almost complete rewrite of cups printers handling was foreseen and preferred, so I kept it on my tree. I have really not enough skills nor time to do such a complex job. My patch was just sending the missing page size string to lpr along as printer name, which is by now the only stuff sent. I can understand, of course, that going through lpr is not a very nice way. I'm using the patch for my daily job, it's not dropped. Latters were one testcase (which was meant preparing some gdiplus patches) which was rejected because too long and with meaningless comments and a couple of gdiplus functions that were missing (and are still missing) needed by autocad to run with builtin gdiplus, rejected because contains errors (possible, but which ?) and were a pain to review (h). BTW, about comments, I'm sorry but my memory is not perfect and I tend to forget what I did and why after a couple of monthes, so the reason of maybe over-commenting all my code :-) I tend to disagree with your self evaluation of 'too many'. There is NO such thing in coding. I've seen code with too little comments and then had to figure out what the heck the coder was trying to do inside the code. Of course, talking to the coder resulted in a I know what I'm doing conversation that resulted in no forward movement on a fixable problem that may have resulted in the company's demise. I must say that the must difficult part of writing my engine was to try to figure out what gdi32/winex11 code does, and some comments more woul have been of great help ! This is very true. Code should at a minimum point out where the examples can be found. MSDN is very frustrating when it comes to how a piece of code is supposed to work. What I see here is a lack of assistance from those who grade the code. This is what I consider unacceptable and has resulted in the stoppage of fixes being submitted by folks who 'code for food', that is they write code for a living. I evaluate and support programs for a living. Guess what? I don't recommend that folks use Wine on Macs for production level work. It just is not 'there'. Sadly, these same folks want to walk away from using Microsoft Software because, pardon the phrase, it just plain sucks. It is poorly written and full of bugs (and some of those bugs have been there for years.) I appreciate AJs efforts to keep the code base 'clean'. In the process, however, you have to tell folks what to do in order to keep the base clean. That is just plain being nice and is good ettiquitte. Otherwise, all you are doing is attempting to shoo away those who could really help move the project along and fix long standing problems. It does not take more time to state: Your code does not meet Wine standards because it has tabs in it, then to say You can do better.Adding comments to what a certain chunk of code does is not expensive and it does make troubleshooting code much easier at a later time by a different person. One line comments are best. So what say all, shall we try to make coding better and as Max stated, fun. Most of the folks here do not support this project for a living and we should not restrict this project to those who do. However, it appears that a vast majority of the patches are coming from those who either are long time Wine 'hackers' or those whose living depends on this project's survival. James McKenzie
Re: PowerPC MacOSX work...
mghug...@embarqmail.com wrote: No No No People... Please read the messages before replying. I know the difference betweeen my 6502, 6800, Z80, 68k, x86, 7400. I know Wine is focused on running MSWindows based software on x86 processors. I also know there exists PowerPC code in the wine project because people were interested in bridging the gap to running x86 code via emulation... For the record... I am not looking to run another full out emulation. The best example of what I have in mind is what Apple did when they moved their processor base from 68K to PPC. And I am wondering if the same could be done for Wine. By the looks of things some of the framework to make that happen are already there in the form of thunk code... Apple used what they called trampolines iirc. The question is: Were there any programs written for WindowsNT for the PPC? I don't know of any, off hand. The real problem is that most, if not all, Windows based programs were written for the X86 platform. The makes the use of a CPU emulator necessary. I know of only on FOSS project that is working on this, and that is the Qemu (?) project. The Darwine project was trying to combine the PPC-X86 emulator with Wine. Again, this project has stopped progress and probably needs help getting restarted. The Darwine project does exist on SourceForge and could be revived with someone displaying interest in getting it running again. I do have PPC Mac here, but I think I messed up the power port on it and thus batteries are not fully charging. I stopped working on another FOSS project because running the test suite takes over a day and I could not trust the power supply to last that long. James McKenzie
Re: Changing default severity in Bugzilla to Normal
Austin English wrote about Re: Changing default severity in Bugzilla to Normal On Thu, May 28, 2009 at 1:40 PM, Ken Sharp kennyb...@o2.co.uk wrote: It seems the default severity, enhancement, invites people to select a REALLY SEVERE sounding level instead. I suggest changing the default severity to normal in the hopes of cutting down on the yelling. http://bugs.winehq.org/show_bug.cgi?id=13363 Any thoughts on this? +1 +1 James McKenzie
Re: patch wined3d
Pavel Prochazka wrote:
static HRESULT WINAPI IWineGDISwapChainImpl_Present(IWineD3DSwapChain *iface,
CONST RECT *pSourceRect, CONST RECT *pDestRect, HWND hDestWindowOverride,
CONST RGNDATA *pDirtyRegion, DWORD dwFlags) {
IWineD3DSwapChainImpl *This = (IWineD3DSwapChainImpl *) iface;
-IWineD3DSurfaceImpl *front, *back;
+IWineD3DSurfaceImpl *front, *back,*hlp1,*hlp2;;
You need to keep the same spacing as the remainder of the line.
-{
-HDC tmp;
-tmp = front-hDC;
+{
Get rid of the trailing whitespace, it is not needed nor necessary.
-
-tmp = front-resource.allocatedMemory;
+
Same here. You should go through your additions and make sure that no trailing
whitespace exists on any line.
Also, you should combine all of your fixes into one patch until it is accepted.
Lastly, a description should describe what your patch does:
[wine3d] Create swapchains to eliminate problems with backbuffers (bug XXX
{there are at least five bugs with backbuffer problems})
Also, provide test cases to prove that your patch actually does something that
Windows(TM) does and to show that you did your homework.
Again, as one of the people with the backbuffer problem causing FPS slowness, I
am very interested in these patches. However, they need to be cleaned up so
that we can use them.
James McKenzie
Re: DIB engine
As was said in the other thread, just designing it alone would take a few months work. AJ is really busy with other things, and a few months work is both a lot of money and a lot of wasted productivity. No one is stepping up to sponsor the work, so it's a bit hard for him to take that on. Who is asking AJ to do all of the work. Huw Davies and Max have worked out what is needed to get this into Wine. All we need is guidance on what is acceptable and how we should proceed. This seems to be a serious shortcoming on AJs part. Without this, any further work would be futile and could end up being very frustrating. I've seen this from Huw and it is starting to come from Max. AJ needs to get some time together and write up what is and is not acceptable as far as code style, fashion and what he expects out of the development efforts for the DIB engine. Making a statement after months of work is IHMO very unacceptable. Also, I don't see this as circular, but the 'snake' of getting AJ to accept code into the codebase is. Very respectfully submitted, James McKenzie
Re: DIB engine
Luke: Heh, I wonder if someone should approach Autodesk and say, Give us sponsorship and we'll get Autocad running on Linux they surely have deep pockets :) If Autodesk were interested in making AutoCad work with Linux, they would make a native version, not try to get it working with Wine. Sorry, but them's the facts. Now, if you were to speak up with your wallet and donate to the effort, that is a vastly different story. Sadly, we are on our own to get AutoCad fully working with Wine. I don't expect any assistance from AutoDesk nor any of the major Linux players. James McKenzie
Re: Time to remove obsolete platforms HP, SGI, and DEC?
Why do we have versions on Mac OS X? How about we combine them all? It can make a big difference in the bug. The X.org version in OS X (partially?) depends on what OS X version you have. Some bugs will only show up in Tiger, because Leopard has them fixed on Apple's end. (Someone correct me if I'm wrong here, this is based off of what I've seen on wine-users). Very much correct. MacOSX 10.5.7 with XQuartz 2.3.3 or higher correctly utilize all OpenGL features present in Wine. MacOSX 10.4.x or MacOSX 10.5.6 or MacOSX 10.5.7 without XQuartz 2.3.3 applied will not. Since I am running MacOSX 10.5.7 with XQuartz 2.3.3.2 applied, I do not know the status of backporting the fixes to the 10.4 (Tiger) baseline or even if it is possible. As far as OS/2 goes, it is still a viable operating system, but I think, for Wine purposes, it should be dropped as an available OS for bugzilla and for the AppDB. James McKenzie
Re: WIne DIB
Ben Klein wrote: Stop making new threads about this! We've already had too many DIB Engine threads! +1. Please keep all of the traffic on the DIB engine to one thread. James McKenzie
[Fwd: Re: DIB engine]
To the list as well. Original Message Subject:Re: DIB engine Date: Mon, 01 Jun 2009 19:09:15 -0700 From: James McKenzie jjmckenzi...@earthlink.net To: Andrew Eikum and...@brightnightgames.com References: a71bd89a0905301414j5bd70f74y3441d367b49bc...@mail.gmail.com 1243755935.4535.1.ca...@stephan-desktop 4a22ad55.5020...@brightnightgames.com b6bb06270905311154w2b9ccb12jee6d64ea587f9...@mail.gmail.com 4a22d65a.3030...@brightnightgames.com Andrew Eikum wrote: Austin English wrote: On Sun, May 31, 2009 at 11:16 AM, Andrew and...@brightnightgames.com wrote: My name's Andrew Eikum, I'm an undergraduate Computer Science student at the University of Minnesota. I contacted a Wine dev a few weeks ago asking for a small project to use to get familiar with Wine. I was pointed towards the gdiplus section and told to begin stubbing out the missing functions, to facilitate debugging. After familiarizing myself with how Wine's DLLs are built, and with Git, I'm now making quick progress. I expect to have a (huge) patchset ready in the next week or two with most of the gdiplus functions stubbed. After that, I plan to begin work on implementing some of the functions. My degree's emphasis is computer graphics, so working on gdiplus will give me a chance to learn more about the field as well as apply what I already know. I'm looking forward to working with other Wine devs on gdiplus, and other parts of Wine in the future. Welcome to Wine! Be sure when sending patches to break them into small sets, with one change per patch. It makes it much easier to review that way, and if your patch causes a regression, much easier to identify which part if it's in multiple patches. Thanks for the welcome! I am definitely doing small commits and following the WineGit wiki page. One concern I have is that the number of patches will probably be over 50 or even 75 -- I'm not sure if it'd be better to submit them all in one go as they're pretty much all alike (just stubbing), or just do batches of 5-10 every couple days as I finish them (so it's not a deluge of patches). Any suggestions? I'll second what Austin said. Please send in like the following: [1/2] Test for some gdiplus Windows function with todo_wine wrapper that demonstrates default Windows function from a source other than reverse-engineering (this is an absolute no-no.) [2/2] Code that implements the default function along with code to remove todo_wine wrapper. This way if your second code breaks something, the test will be in place and the todo_wine wrapper will remain. James McKenzie
Deadlock under Supreme Commander in d3d9 main.c
As reported in another thread, Supreme Commander's graphic display slows considerably (1 FPS), and if run in a terminal session a large number of lines are show in the terminal, but one line in particular is interesting to the poster: Additionally, I am using a GeForce 7600GS card with the latest drivers (180.60, I believe - I'm not in front of it right now, but it's definitely the latest) The error itself is: Code: err:ntdll:RtlpWaitForCriticalSection section 0x7e114810 d3d9_main.c: d3d9_cs wait timed out in thread 001f, blocked by 0009, retrying (60 sec) This appears to be a revisit of the deadlocking issue as reported in bug 14746, but according to another triage person, this is not so. I would like to know if code has been moved from x11drv.c to d3d9_main.c that would cause this error and for the framerate to drop considerably. Thank you. James McKenzie
Re: [3/5] WineD3D: Unroll loops in ARB if GL_NV_vertex_program2_option is not supported
Stefan Dösinger ste...@codeweavers.com wrote about [3/5] WineD3D: Unroll
loops in ARB if GL_NV_vertex_program2_option is not supported
Stefan:
Could this not a be a function:
+for(i = 0; i MAX_CONST_I; i++)
+{
+if(int_skip (1 i))
+{
+args-loop_ctrl[i][0] = 0;
+args-loop_ctrl[i][1] = 0;
+args-loop_ctrl[i][2] = 0;
+}
+else
+{
+args-loop_ctrl[i][0] = stateblock-pixelShaderConstantI[i * 4];
+args-loop_ctrl[i][1] = stateblock-pixelShaderConstantI[i * 4 +
1];
+args-loop_ctrl[i][2] = stateblock-pixelShaderConstantI[i * 4 +
2];
+}
+}
Also, it looks like you did not count correctly:
+if(vshader)
+{
+/* Count and aL start value are unsigned */
+ret[0] = priv-cur_vs_args-loop_ctrl[idx][0];
+ret[1] = priv-cur_vs_args-loop_ctrl[idx][1];
+/* The step/stride is signed */
+ret[2] = ((char) priv-cur_vs_args-loop_ctrl[idx][3]);
+}
+else
+{
+ret[0] = priv-cur_ps_args-loop_ctrl[idx][0];
+ret[1] = priv-cur_ps_args-loop_ctrl[idx][1];
+ret[2] = ((char) priv-cur_ps_args-loop_ctrl[idx][3]);
+}
+return ret;
A little explanation might help here.
James McKenzie
Re: wined3d:
Pavel Prochazka wrote: There is an open bug for this problem, 14746. Can you clean up and attach your fix to this bug so that others can try it? I did apply it cleanly, through three steps to version 1.1.22 of Wine. James McKenzie
Re: Disable forum edits
Subject: Re: Disable forum edits On Fri, Jun 12, 2009 at 12:51 PM, Jeremy Newmanjnew...@codeweavers.com wrote: Editing disabled. -Newman Thanks! +1 James
Re: winex11: Get rid of glext.h in remaining locations [try 2]
Austin English austinengl...@gmail.com wrote about Re: winex11: Get rid of glext.h in remaining locations [try 2] On Fri, Jun 19, 2009 at 9:02 AM, Detlef Riekenbergwine@web.de wrote: Already removed from dlls/opengl/* by Roderick. winex11 on linux works without GL/glext.h (OSX untested) Now with configure.ac Works fine on OS X. Sorry I forgot to do this myself. Thank you. I have not set up my build system, yet. James McKenzie
Re: Pavel Procházka's commit
Pavel Procházka pavelvonlost...@seznam.cz wrote about Pavel Procházka's commit Needs a more descriptive title here. Need to state what module/file the patch affects. One patch per patch message. Order them in the manner they should be installed and mark with [n/x] where n is the patch number and x is the number of patch files. Need to use spacing for your patches OR follow the pattern in use in the file. Tab stops are HIGHLY discouraged. Add test cases, if needed, to demonstrate what you are attempting to do is what Windows(TM) does with the same inputs. James McKenzie
Re: wine 1.1.23 configure message Mac OSX 10.5.7
Austin English wrote: On Sat, Jun 13, 2009 at 2:47 AM, Maurits Lamersmaur...@weidestraat.nl wrote: Hi, while running configure of wine 1.1.23 on Mac OSX Leopard 10.5.7 the message below appeared with a request to mail it. Running XCode 3.1.2, i686-apple-darwin9-gcc-4.0.1. Please feel free to contact me if you need any extra information. greets Maurits checking mach-o/dyld_images.h usability... no checking mach-o/dyld_images.h presence... yes configure: WARNING: mach-o/dyld_images.h: present but cannot be compiled configure: WARNING: mach-o/dyld_images.h: check for missing prerequisite headers? configure: WARNING: mach-o/dyld_images.h: see the Autoconf documentation configure: WARNING: mach-o/dyld_images.h: section Present But Cannot Be Compiled configure: WARNING: mach-o/dyld_images.h: proceeding with the preprocessor's result configure: WARNING: mach-o/dyld_images.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to wine-devel@winehq.org ## configure: WARNING: ## ## http://www.winehq.org/pipermail/wine-devel/2009-June/076443.html This did make it into git, right? James
Fw: Re: Removing active maintainers
Sent to Rosanne only, meant to send it to the list as a comment to this thread. James McKenzie -Forwarded Message- From: James Mckenzie jjmckenzi...@earthlink.net Sent: Jun 29, 2009 6:36 PM To: Rosanne DiMesio dime...@earthlink.net Subject: Re: Removing active maintainers Rosanne DiMesio dime...@earthlink.net Subject: Re: Removing active maintainers On Mon, 29 Jun 2009 14:56:23 +0200 Remco remc...@gmail.com wrote: On Mon, Jun 29, 2009 at 2:22 PM, Rosanne DiMesiodime...@earthlink.net wrote: That would still leave the test results sitting there unprocessed for weeks, which leaves a pretty bad impression on the users who submitted them. Test results for apps without maintainers get processed by the admins within 24 hours. How about mailing admins after 24 hours? Maintainers are useful to offload tasks of admins. If they are away for a while, admins just get the mail as if there were no maintainer. If you have to remove a maintainer every time he can't respond in 24 hours, you won't have many left after a while. Remco Nobody's suggesting a 24 hour time limit for maintainers. As for emailing the admins, I know I turned off emails from the AppDB to avoid having my mailbox overwhelmed with hundreds of useless notices every day, and I doubt I'm the only one who did this. http://bugs.winehq.org/show_bug.cgi?id=14755 needs to be fixed first for any solution that involves emailing admins to be viable. I see several good ideas here: 1. Maintainers should be able to mark themselves as not available. No reason should be required. 2. Admins should have the ability to suspend a maintainer for non-response. There are several reasons for not responding and most of them would be considered an emergency. 3. Any maintainer who fails, after three suspensions, to properly carry out the functions of being a maintainer, should be banned for a specific period of time, increases to a complete ban. 4. What maintainers have to do to maintain their status should be posted on the Maintainers page when you sign up and a reminder message every 90 days or so should be sent out to keep maintainers honest. 5. Maintainers should be given the option of gracefully resigning when they no longer can perform the duties of their position. James McKenzie -- Rosanne DiMesio dime...@earthlink.net
Re: RFC: Mac OSX should use existing Pictures/ Music/ Videos/ etc. directories - how exactly?
You probably want a separate code path in shellpath.c for the Mac. I don't think XDG works there. Can check, but make sure you do not use ObjC code. AJ will reject. Also pass to me, and I will add/test it. James McKenzie
Re: Ensure that GetSystemMenu returns valid HMENU unless bRevert specified
Brent Roman wrote: Originally submitted on 6/14/09. Resubmitted after comments on this bug: http://bugs.winehq.org/show_bug.cgi?id=19134 The attached patch against the master branch (as of today) fixes what appears to be a long standing bug in Wine's GetSystemMenu function in User32.dll.so. GetSystemMenu() is always supposed to return a valid HMENU handle, but the logic in Wine's version would return nil in some cases where windows would return an HMENU. Specifically, when the relevant windows dwStyle mask did not include WS_SYSMENU, wine would return nil, but windows would still return a valid HMENU. To reproduce the bug: 1. Download and install the Quadravox AQ430 development tools from: http://www.quadravox.com/AQ430.htm http://appdb.winehq.org/objectManager.php?sClass=applicationiId=9939 2. Attempt to compile any 'C' source file. Before applying the patch, all such attempts will quickly fail with an invalid read from address 0x4. You rewrote the entire function, there is no need to do this. Please use the same formatting as the rest of the code. Add new variables to the bottom of the list, you imbedded one or more. Since the rest of the function uses four spaces, use them. Avoid the use of tabs, some editors spread them to four spaces, some two and yet others eight. Makes the code look sloppy and is very hard to read. Can you provide test cases, other than 'use this program to prove it works'? The idea is to replicate Windows API functionality and some programs rely on certain functionality working in a very specific manner. If you build to the program, you might break others. Also, if you have left out some function, please insert c style notes stating this. Makes it easier to find where certain code pieces go at a later time. James McKenzie
Re: server/fd.c: Prevent using uninitialized pointers
Henri Verbeet wrote: 2009/6/30 Daniel Santos javatroubad...@yahoo.com: Some pointers are getting used prior to initialization. It would appear that the current compilers are initializing them to zero or we've been lucky. No, the C standard specifies that these are initialized to NULL, since they have static storage duration. We are assuming that the c compilers are following the standard. I was told a long time ago, 1994 to be exact, that if we want to insure that a variable has a certain value to initialize it to that value. This applies if we want a zero or a NULL. [code] int a = 0; char b = NULL; bool c = TRUE; [/code] Without this, we cannot assume anything. James McKenzie
Re: fix overflow in several advapi32 crypt functions hidden by broken WideCharToMultiByte
Christoph von Wittich wrote: As Dmitry wrote about this, I will add the comment that this does not look like the proper way to fix this problem. The proper way is to keep the pointer from overflowing in the first place and that would be to place a check where it is set and updated to either go negative (which should not be allowed) or to be incremented past INT_MAX. This can be implemented in several different ways, and since I have not looked at the code, I could not make a proper suggestion but would suggest that the pointer be checked before incrementing and after setting. James McKenzie
Re: server/fd.c: Prevent using uninitialized pointers
Vitaliy Margolen wrote: James McKenzie wrote: [code] int a = 0; char b = NULL; bool c = TRUE; [/code] Without this, we cannot assume anything. Static variables are different. They are always initialized to 0. In your example you show regular variables only. Their initial value is not defined. Correct. I was making the assumption that the discussion was not about static variables. Static variables are always initialized: static int a; will be zero static char b; will be NULL static bool c; will be set to false (0) unless zero is defined as TRUE. However, if you want a particular result, it is always best to initialize the variables you are going to use. James McKenzie
16-bit Code on MacOSX Leopard/XCode 3.1
I know that this was disabled, but what happens when I try to run a 16 bit app? Here is what happened when I tried to build 1.1.25 with XCode 3.1 today: checking whether 16-bit code can be built correctly... no configure: error: Xcode 3.x cannot build 16-bit code correctly. Use --disable-win16 if you don't need 16-bit support. * Error: Can't build wine Great catch, BTW. James McKenzie
Re: 16-bit Code on MacOSX Leopard/XCode 3.1
King InuYasha wrote: On Sat, Jul 4, 2009 at 4:25 PM, James McKenzie jjmckenzi...@earthlink.net mailto:jjmckenzi...@earthlink.net wrote: I know that this was disabled, but what happens when I try to run a 16 bit app? Here is what happened when I tried to build 1.1.25 with XCode 3.1 today: checking whether 16-bit code can be built correctly... no configure: error: Xcode 3.x cannot build 16-bit code correctly. Use --disable-win16 if you don't need 16-bit support. * Error: Can't build wine Great catch, BTW. James McKenzie As far as I know, GCC cannot be used to build 16-bit code... Yes it can. The '16 bit' code in Windows is actually a series of thunks that allows 16 bit code to execute in 32 bit space. Has been since Windows95. The problem is that XCode 3.x will not build this code correctly for some reason. I have a guess, but I could be wrong and that would lead to legal problems. James McKenzie
Re: why is Kronenberg's Wine/Mac work blacklisted on winehq?
Mike Kronenberg wrote: On 26.06.2009, at 16:51, Dmitry Timoshkov wrote: Emmanuel Maillard maha...@free.fr wrote: Darwine tools WineHelper and create_darwine_distrib script are not GPL but LGPL. Don't know for Mike Kronenberg patches or other stuffs, but we never change Wine licensing in Darwine. Darwine site claims that it's under GPL. In any case different name means a different product regardless of claims and intentions. Darwine is not Wine, plain and simple. -- Dmitry. This is very true. Prolog The main purpose is here, like with other people, to have a crossdev option. I just share the outcome, i.e. binaries. OS X My main concern is to have usable builds. Ie, usable without the need of a terminal. People on OS X don't care about how stuff works, it just has to work. Vanilla build I totally agree that by adding certain patches, the builds can't be considered as vanilla. I'll recheck the necessity of the patches again on Tiger and Leopard and they really get less and less. Added libs As pointed out, the build ships with some libs not installed by default on OS X. My solution is to hide them inside the app folder, this way they are not installed in the users /usr or /opt. Drag the folder to trash and they are all gone at once. Clean system. Next try. Something that I do have to point out is that freetype, a very important library for Wine is not shipped with XCode nor MacOSX. We have to include it. Both MacPorts and Fink's builds make this a dependency and force you to install it. Fortunately, Fink puts it in a place where installing other software with freetype (and the other libraries required for Wine) do not interfere with each other. Right now, a 'vanilla' build of Wine using just Wine code on MacOSX is not possible. There are dependencies, just like there are on Linux. The X11SDK is not installed and that is just a start... And Mike's builds are LGPL, just like Wine's. James McKenzie
Re: Building problems on Intel Mac.
Zheng Che wrote: Screenshot attached. It may be better to use MacPorts or Fink to install Wine. They know about and handle the required dependencies for you. Also, Mike Kronenberg's build environment for the 'abandoned' Darwine project is also available, but needs to be updated to reflect the latest versions of several packages. James McKenzie
Re: winequartz.drv Mac OS X UI discontinued?
Emmanuel Maillard wrote: Le 11 avr. 09 à 18:20, James McKenzie a écrit : Emmanuel Maillard wrote: Le 3 janv. 09 à 04:14, James McKenzie a écrit : Emmanuel Maillard wrote: Hi, Le 4 juil. 08 à 12:37, Adam Strzelecki a écrit : Hi Emmanuel, hello Wine developers, Latest WineQuartz.drv patch is 0.9.58. Is there any change for more recent release? I tried this patch with 1.0-1 however it has too many conflicts. It would be most convenient if you had just update http://repo.or.cz/w/wine/winequartzdrv.git to match 1.1.0 somehow and include Quartz. I resolved conflicts for wine-1.0, but didn't take a look yet for wine-1.1.0, i just know that's some changes in user32 and winex11.drv have to be update in winequartz.drv too. I will see this week end if i can find free time to make a new patch for winequartz.drv and send it to SourceForge. (OpenGL is broken in winequartz.drv actually, because of a lack of time to fix it) Since Wine passed 1.0 (woohoo!) maybe someone from the direction can revise Mac support? Even there're numerous Emmanuel efforts to provide Mac UI driver instead of X11, it will be always pushed aside, and sentenced to death, because it is not in official sources. I know Alexandre Julliard's decision about NOT taking any Objective- C sources (.m) into the Wine, but maybe this can be revised, anyway all .m rules will be only present on Mac platforms. Using Objective- C is only way to make fair support for Mac OS GUI, as those whole GUI system is objective. Moreover then what's the point of keeping winex11.drv and all GUI driver infrastructure in Wine if nothing else but X11 is NOT accepted into official source? Forgive me what I say now, but I just it would be more fair if someone from Codeweavers just said that Wine's official support for Mac OS X is against their business with CrossOver and this is the real reason they reject winequartz.drv from Emmanuel Maillard. Frankly I'd really pay for CrossOver or Wine, if it was what 1.0-1 is but with native Mac UI, so each wine process has it's own dock icon, and no X11 is needed and native Mac font system. Regards, -- Adam Strzelecki |: nanoant.com :| Cheers Emmanuel Emmanuel: What is the status of winequartz.drv? It looks like your last patch was for 1.1.2. James McKenzie Hi, I didn't really work on winequartz.drv since this patch, start a new version at the beginning of October, but more or less waiting for DIB engine. Emmanuel Emmanuael: Are you still working on this or have you abandoned it? James McKenzie Hi, I stopped working on winequartz.drv for now ... abandoned ? not totally, but i currently do not envisage to work again on it. Emmanuel: At one time you stated that this work depends on a DIB engine. Have you looked at Max' work? Also, did work get finished on 1.1.2 or did that stop as well? James McKenzie
Re: winequartz.drv Mac OS X UI discontinued?
Adam Strzelecki wrote: I googled a bit more. There are at least two ways of achieving this mentioned in the docs of libFoundation: by using XML-RPC call and by wrapping classes in ANSI-C APIs. [4] Well actually you can easily access all Obj-C features trough the following pure C API: http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html Adam: Is this still true? I would like to convert what work we do have into c level code so that it will pass AJs 'c' scan and to avoid using ObjC code. In addition, if an exported Carbon/Cocoa library exists, this would help move the project along. James McKenzie
Re: why is Kronenberg's Wine/Mac work blacklisted on winehq?
James McKenzie wrote: Something that I do have to point out is that freetype, a very important library for Wine is not shipped with XCode nor MacOSX. We have to include it. Huh? On my 10.5.7 Leopard system, Wine was able to find FreeType -- with LD_LIBRARY_PATH guidance. And I have nothing but - MacOS (with iLife preinstalled) - (selected packages from) the Xcode install DVD and - XQuartz 2.3.3.2 installed on that box. Did you install Apple's X11 before installing XQuartz, as the XQuartz site recommends? Are you mislead by the following error message? Possibly. I will check my system and see if libfreetype exists in /usr/X11/lib. James McKenzie
Re: why is Kronenberg's Wine/Mac work blacklisted on winehq?
joerg-cyril.hoe...@t-systems.com wrote: James McKenzie wrote: Something that I do have to point out is that freetype, a very important library for Wine is not shipped with XCode nor MacOSX. We have to include it. Huh? On my 10.5.7 Leopard system, Wine was able to find FreeType -- with LD_LIBRARY_PATH guidance. And I have nothing but - MacOS (with iLife preinstalled) - (selected packages from) the Xcode install DVD and - XQuartz 2.3.3.2 installed on that box. Did you install Apple's X11 before installing XQuartz, as the XQuartz site recommends? Are you mislead by the following error message? snip Wine cannot find the FreeType font library. To enable Wine to use TrueType fonts please install a version of FreeType greater than or equal to 2.0.5. http://www.freetype.org Building font metrics. This may take some time... Font metrics: 0.0% done fixme:font:LFD_InitFontInfo DBCS fonts like '-daewoo-gothic-medium-r-normal--16-120-100-100-c-160-ksc5601.1987-0' are not working correctly now. ... http://bugs.winehq.org/show_bug.cgi?id=17674#c4 I saw those on my first compile make ./wine winecfg LD_LIBRARY_PATH=/usr/X11/lib ./wine notepad prevents those messages. Wine then starts up much faster (still slower than a slower Ubuntu box, some people suppose that is due to the many fonts) and does not re-generate font data for *every* subprocess ran inside Wine. LD_LIBRARY_PATH=/usr/X11/lib is needed because libfreetype.* is there. If you want, I'll try to identify (using pkgutil) what package installed /usr/X11/lib/libfreetype.*. It's there. I'll check Fink to see what the latest versions are and how they compare. James McKenzie
Re: why is Kronenberg's Wine/Mac work blacklisted on winehq?
joerg-cyril.hoe...@t-systems.com wrote: BTW, it would be nice if MacOS users could comment on a) my comment #4 to bug #17674 above or on b) my patch http://www.winehq.org/pipermail/wine-patches/2009-July/075290.html It was not included in Wine-1.1.25 perhaps because AJ awaits confirmations from other users? That patch looks very familiar. I think it is the fallback path that Mike uses. James McKenzie
Re: winequartz.drv Mac OS X UI discontinued?
Just to explain things better, I found great sample of calling Obj-C API within pure C program: http://www.smipple.net/snippet/moriyoshi/Using%20Objective-C%20ABI%20from%20within%20a%20pure%20C%20code . This is basic application that just displays a single window, and YES it works! BUT it is 400 lines of code, it is totally obscure. Having it natively in Obj-C would be ~50 lines of small clean code. So this is what a call a nightmare, or maybe happy coding. Or maybe job security. However, we have a requirement that any code submitted to the Wine project be either c or C++. ObjC cannot be included, however. I would like to see it 'wrapped' so that it could not be compiled and then the world would be upright (and this is how several other projects do this as well.) James McKenzie
Re: winequartz.drv Mac OS X UI discontinued?
Adam Strzelecki wrote: Just to explain things better, I found great sample of calling Obj-C API within pure C program: http://www.smipple.net/snippet/moriyoshi/Using%20Objective-C%20ABI%20from%20within%20a%20pure%20C%20code. This is basic application that just displays a single window, and YES it works! BUT it is 400 lines of code, it is totally obscure. Having it natively in Obj-C would be ~50 lines of small clean code. So this is what a call a nightmare, or maybe happy coding. Ugly, but if this will work, it works. I don't like code obfusicusion just to have it there. I like clean, commented, understandable code. Unfortunately, we have to stick with c/C++ code here. I'm wondering if there is a C++ to ObjC library interface that would be cleaner. James McKenzie
Re: winequartz.drv Mac OS X UI discontinued?
Emmanuel Maillard wrote: Emmanuel: What is the status of winequartz.drv? It looks like your last patch was for 1.1.2. James McKenzie Hi, I didn't really work on winequartz.drv since this patch, start a new version at the beginning of October, but more or less waiting for DIB engine. Emmanuel Emmanuael: Are you still working on this or have you abandoned it? James McKenzie Hi, I stopped working on winequartz.drv for now ... abandoned ? not totally, but i currently do not envisage to work again on it. Emmanuel: At one time you stated that this work depends on a DIB engine. Have you looked at Max' work? Also, did work get finished on 1.1.2 or did that stop as well? James McKenzie Hi, No, I not have not looked at Max DIB Engine yet. I waited for an official version, if ever this one had to come in Wine tree ... Patch for wine 1.1.2 was only an update of configure.ac, nothing more, so not really useful at present time. I said it to you previously, I started a new winequartz driver in October. So Yes, I stopped working on my old hack. Any real progress? James McKenzie
Re: winequartz.drv Mac OS X UI discontinued?
Adam Strzelecki wrote: Never encountered any. I doubt it is possible since Obj-C is dynamically typed (binded) language, which means you can pass any kind of msg to any kind of obj and it will compile/run. Either you will receive an method not found exception or nil as return. It is very close to what Ruby is. Actually both Ruby ObjC as based on Smalltalk idea. Now I understand. It is very interesting that Obj-C is based upon something that I actually have an idea of how it works... Of course there's wxWidgets for example which wraps Cocoa as one of its backends, but the wrapper is C++ ObjC mixture. I really don't understand why Obj-C is treated as evil, even it would be part only of Mac platform of Wine and even it is supported by GDB and GCC on any possible platform :/ Need to convince AJ of that. It would be nice to be able to do Mac builds on Linux and vice versa. I don't like the problems that are encountered using mingw32 for the testsuite when building it on Linux. Once I thought when moving to Mac that its doggy idea to force some Obj-C on Mac, while other part of the World speak C/C++, but now I know that Obj-C is what defined OSX actually and way the whole system works. So wondering who of Obj-C dislikers at Wine HQ really uses Mac and really did any of native apps on Mac. Don't know. I know that Austin English does use a Mac. I don't know if he builds programs on it, however. I would like to see at least one FOSS project use Obj-C code to support the Mac rather than using c wrappers. James McKenzie
Re: winequartz.drv Mac OS X UI discontinued?
Austin English wrote: On Sat, Jul 11, 2009 at 4:21 PM, James McKenziejjmckenzi...@earthlink.net wrote: Adam Strzelecki wrote: I really don't understand why Obj-C is treated as evil, even it would be part only of Mac platform of Wine and even it is supported by GDB and GCC on any possible platform :/ Need to convince AJ of that. It would be nice to be able to do Mac builds on Linux and vice versa. I don't like the problems that are encountered using mingw32 for the testsuite when building it on Linux. What problems are you referencing? The fact that the test suite was not working properly if built using mingw32 vice building it with MS tools. If this has been overcome, good work for the devs. Once I thought when moving to Mac that its doggy idea to force some Obj-C on Mac, while other part of the World speak C/C++, but now I know that Obj-C is what defined OSX actually and way the whole system works. So wondering who of Obj-C dislikers at Wine HQ really uses Mac and really did any of native apps on Mac. Don't know. I know that Austin English does use a Mac. I don't know if he builds programs on it, however. I would like to see at least one FOSS project use Obj-C code to support the Mac rather than using c wrappers. No, I don't have one. I have ssh access to one, but that's it. I'd like to see more testing done on the Mac, but until I get one personally, that won't happen for a while. There is nothing like owning one(I have three, my partner two, just for the record, I also own a Thinkpad A22p, that was the last PC I will buy unless Apple disappears.) As to testing, what needs to be done? I would like to see a native version of Wine for the Mac, vice the requirement to use X11. That of course, may be years away (I worked with both the NeoOffice.org and OpenOffice.org projects with this. It was a multi-year adventure.) James McKenzie
Re: FW: Re: winequartz.drv Mac OS X UI discontinued?
Rolf Kalbermatter wrote: On Thursday July 09, 2009 5:32 PM Chris Robinson wrote: If OSX will always have Obj-C support, and the Obj-C code can be restricted to OSX-only code, then the only sticking point, in my eyes, would be how maintainable it is. After all, if only one or two people can work with Obj-C code, it can bit-rot that much more quickly. I think this is in fact the major issue here. There is certainly interest in starting such a project but maintaining it is a completely different beast. This may be AJ's major concern. I don't know of many Obj-C programmers on this project. James McKenzie
Re: [Request for review] wrc: Add support for nameID with quotes
Alexandre Julliard wrote: Matijn Woudt tijn...@gmail.com writes: Thanks, didn't notice that one. I've checked it with the rc from visual studio 2008 and you're right, it's really mysterious(just like the rest of windows). Single and double quotes are just copied, but only if they are in pairs. Though, there can be a single quote within two double quotes, and the other way around. I've attached a patch for this behaviour, is it ready to send to wine-patches? I expect it will break parsing of normal strings. As you state (AJ): A test case would be great to show what Windows(TM) and what Wine does to see if the patch really fixes the problem. James McKenzie
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
Juan Lang wrote: Hi Joerg, please make suggestions about the xyz_LIBRARY_PATH MacOS issue that allows libpng.so and libfreetype.so to be found at run-time in /usr/X11/lib (bug 17674). I agree with Alexandre on this one: it's just an error in your configuration. You can address it by adding /usr/X11/lib to LD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH in your ~/.bash_profile or ~/.bashrc if you like, assuming you start wine apps from the command line. If you use some other launcher, the environment needs to be set correctly for that. No, I won't and I can't. So there. Wine will need a startup script to fix this problem. That is what Zach Drayer and Mike Kronenberg do. This is what OpenOffice.org does. Fink and MacPorts both build their own LD_LIBRARY_PATH and permenantly alter it. James McKenzie
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
Steven Edwards wrote: On Tue, Jul 14, 2009 at 4:17 PM, Juan Langjuan.l...@gmail.com wrote: I agree with Alexandre on this one: it's just an error in your configuration. You can address it by adding /usr/X11/lib to LD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH in your ~/.bash_profile or ~/.bashrc if you like, assuming you start wine apps from the command line. If you use some other launcher, the environment needs to be set correctly for that. Another way of looking at the error is that MacPorts (and fink, I presume) install libraries to a path that's not searched by default. Perhaps this is what you want, and perhaps not, but that's up to you, not up to Wine. Since OS X does not provide some of the libraries that we need, should we have a dependency build script that installs those libraries to a standard location (so the users don't need to install MacPorts of Fink just to get Wine) or should we ask them to go mucking with the ~/.bashrc? Neither. We need to provide an Applescript starter that sets several variables. This is what the OpenOffice.org project decided to do. This would only exist on the MacOSX version of Wine, not Linux. It is not 'rocket science' to makd this happen. James McKenzie
Re: which release of Wine created or last updated this particular .wine/ tree?
joerg-cyril.hoe...@t-systems.com wrote: Ken Sharp wrote: Is anything dropped into the registry? No. One of my .wine/ trees uses Git and I can tell that for some releases, there are no changes in the registry except for the time stamp of some keys (...\\Fonts among them). It would not be nice to add some registry just to track the version. One idea I had was to use the 0-length .wine/.update-timestamp and write a version string into it. Of course that would not help for past releases. BTW, putting .wine under version control is a great way to assess what an application installs. +1, from a CM kind of guy. James McKenzie
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
Emmanuel Maillard wrote: If you build your package in standard path (/usr/local for example) you may not need DYLD_FALLBACK_LIBRARY_PATH (see man dyld for default path). This is good, but we should be using the packages in /usr/X11/lib first. Let me check if this is set on my system. I thought and confirmed it is not. This would need to be set in the session(s) that Wine would be running in. If you make a complete bundle for Wine, you'll need it, but it may be set dynamically, while initializing wine lib, see get_runtime_libdir. That is one solution. Now using a bundle or an installer for packing Wine ? IMHO bundles are more friendly to end users. Bundles are WAY more friendly than using the installer. Installer programs are meant to remain on the system. James McKenzie
