Re: Updating GSoC proposal
On Tue, Mar 20, 2012 at 2:41 AM, Jacek Caban wrote: > > Cleanup Winemenubuilder to support generating Application Bundles on Mac > OS X There is a much better version of my patch for this on the morth-wine tree on GitHub. It just needs to be broken up and submitted by someone that cares. If a SoC student shows up with interest, please send them my way, I would be happy to help point them in the right direction. Our code works, I just don't have the time to break it up and get it in the tree. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Rethinking WineConf
On Tue, Jan 10, 2012 at 8:44 PM, Dan Kegel wrote: > > From what I recall, the Mono people don't really intend > to support those apps; they're more into supporting people > who are writing new apps from scratch. > There needs to be some mechanism to provide for the legacy user, even if they don't want to pick up the ball and run with it. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Testing edge cases and undocumented behavior
On Fri, Aug 26, 2011 at 6:00 AM, Michael Stefaniuc wrote: > It is a good advice. But that doesn't means one has to submit tests that > don't make sense. It seems like a simple comment describing the undocumented behavior would help. I wrote some tests years ago (the details are not important because I don't remember them) based upon something in MSDN and found that I could pass some extra foo and undocumented magic would result. My point is, I wish now I had written down in the form of a one or two line comment, what I saw, so that in the future if I or someone else were tracking down a bug in that component, that little note might save someone else hours of effort. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: winelib an fpc
On Mon, Aug 29, 2011 at 2:05 PM, Reinier Napoles Martinez
wrote:
> lib:=dlopen('/usr/lib/wine/user32.dll.so',1);
This won't work. Simply doing a dlopen on the wine libraries won't get
your environment setup properly.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Re: winemenubuilder: appbundle patch 20110618
Hi Per, On Sat, Aug 20, 2011 at 9:39 AM, Per Johansson wrote: >> I've finally gotten back around to hacking the *.app bundle support in >> winemenubuilder and come close to having something that mostly works. > > I'm attaching my current work, since I'm not sure when I'll work on it next > (might be tomorrow, might be never). Thanks for your feedback on contribution! I am kind of in the same boat, I only hack on this when I get the itch every few months or so. I'll try to test out your changes soon and see if I can contribute anything else. Thanks again! -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: MS compatible interface to xulrunner?
Hi Thomas, On Mon, Jul 19, 2010 at 9:29 AM, Thomas Kaltenbrunner wrote: > Hello, > > I am interested to port the wine interface to the xulrunner back to > mswindows to access the xulrunner via a IE compatible interface. So it would > be easy to replace an embedded IE with the gecko-engine. > After some code browsing I thing it will be some of the "DLLs", especially > mshtml and shdocvw. > I just wanted to hear from you an opinion about that project. > What will be the main changes to the wine code - besides renaming of the > dlls? > Where do you see problems? > Did somebody else worked on that or implemented it already? > > Jacek or one of the Wine IE maintainers will have to help answer this but it seems like if the dlls can currently be built with a Mingw build then it should 'just work' assuming you use something like a side by side assembly with the Wine dlls and a bundled Gecko as opposed to the Windows dlls. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Manifests, Microsoft.VC90.CRT and vc_redist
On Mon, Jul 12, 2010 at 12:44 PM, Peter Urbanec wrote: > > > Can I get wine to ignore the manifests and just load DLLs from the app > directory? > > > I am not sure if our loader was every updated to mimic this behavior (Alexandre and I discussed it before), but older versions of windows used to support local dlloverriding by making a dummy file called appname.exe.local and placing that in the same folder of the application and the dlls you want to load. For example, say you have iexplore.exe and you want to force using some local dlls for testing, you can create a dummy file called iexplore.exe.local which would be placed in the same folder. Like I said, I don't know if support for this was added to Wine, iTunes and Internet Explorer 5 both made use of this behavior under Windows 2000 and it's possible the behavior has changed in newer windows versions. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Wine on cygwin now compiles!
On Sun, Jun 27, 2010 at 4:59 AM, Aleksey Bragin wrote: > Is there any real, practical interest in Wine on Windows? For doing a full port, other than the argument of climbing the mountain because it's there, I doubt it. > I've been making some progress in this direction recently (though I think my > approach would be to have a ported, NT-version of wineserver.exe which just > uses native functions of the OS instead of emulating them over cygwin, which > emulates those features using its own code once again; discussable anyway). I think as we have discussed before, taking arwinss, or at least the core parts of it and attempting to make an independent subsystem that runs under Windows has value. I believe there is a worthwhile product based upon your work with arwinss using Wine user32/gdi32/x11drv with the rest of the Windows stack to support remotely displaying Win32 applications over X11 to OS X, Solaris and Linux clients. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Wine on cygwin now compiles!
On Wed, Jun 16, 2010 at 4:04 PM, Roderick Colenbrander wrote: > I don't expect Wine itself to ever work on cygwin. Last year I asked > AJ about it and there are some special file handle features which are > needed. This stuff is supported in SUA but at least in the Vista > version this was broken. They MIGHT have fixed it for Win7, so if Wine > can work on Windows it would need Win7 but still you would need a > version which supports SUA (which are Ultimate and perhaps some > business version). If anyone is sufficiently interested in the sendrecv message sockets over file descriptor stuff (I know I am not anymore) there may be an archived email with a regression test I found showing the problem. Even though it was now listed as a supported operation, it kinda sorta worked in limited cases under Server 2003 and hung in others which Wine stress. I don't even recall all of the details at this point but it culminated in me presenting my findings to the SUA team developers and them saying 'that's nice, call our support to file a bug report'. Since I could not actually file the bug report myself online and calling Microsoft support is like a $200 (even if they do issue a refund or not charge your CC if it's a new real bug), I decided to waste no more time with it. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Two enhancement requests for winetricks
On Wed, Jun 9, 2010 at 3:45 AM, Dan Kegel wrote: > I suppose winetricks could create uninstaller entries for even > the little verbs... that would be the windows way of doing things. +1 for this idea. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Release plans
On Sat, May 22, 2010 at 12:27 PM, Damjan Jovanovic wrote: > My latest patch set (http://source.winehq.org/patches/data/61966, > http://source.winehq.org/patches/data/61967, > http://source.winehq.org/patches/data/61968, > http://source.winehq.org/patches/data/61969, > http://source.winehq.org/patches/data/61970) moves all icon generation > in winemenubuilder to use windowscodecs and only outputs PNG icons. > This should make it pretty easy to add ICNS icon support. > > If you're going to test this before it gets committed, be sure to also > grab http://source.winehq.org/patches/data/61940 which fixes a nasty > bug in windowscodecs that corrupts many paletted ICO files. I think > this was the cause of the image corruption and RGB/BGR issue Steven > reported in his experiments with windowscodecs in early February. > > Jörg can you test whether you still get icons with black backgrounds > with these patches? YAY! This makes me feel like I was actually close to understanding how it all worked ;) Thanks for all of your work on this. Since I have no clue as to how we should actually implement icns support and how well it is documented I will try to merge in my Appbundler hack once this is all merged in to head. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: too much dynamic loading?
On Sun, May 23, 2010 at 5:20 PM, James McKenzie wrote: > I'm referring to the 'little' things, like openssl. MacOSXs version is not > the same as Linux. Also, the level of library support varies greatly > between versions of MacOSX. > > See my reply to Ryan for more on this. > > Also, we have to keep in mind that there are still Intel Mac users that are > running MacOSX 10.4, which did not come with X11 installed. Not counting X11.app in this but, in the past I spoke with Alexandre about putting together a Winesupport.Framework or some such that would contain all of the libraries required for an offical OS X release and he was not opposed to linking to it on winehq.org and making it part of the support requirements. The problem is that putting this package together and maintain it is going to require a bit of heavy lifting. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: too much dynamic loading?
On Fri, May 21, 2010 at 1:28 PM, Marcus Meissner wrote: > > No static linking either, its the nightmare of security maintainers ;) > > Good point. Direct Linking then. I am just in favor of changing it to something other than the status quo because all of this dynamic loading stuff never wants to work right on OS X. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: too much dynamic loading?
On Fri, May 21, 2010 at 12:59 PM, Marcus Meissner wrote: > As libjpeg and libpng bumped their major versions in the last months > I had to adjust some of my library requires in my wine.spec file. > > This caused me thinking if it is really necessary to dynamically > load nearly every library. > > Can we make some of those direct linking? libjpeg and libpng > and some other lowlevel libraries might be useful. +1 for static linking them. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Release plans
On Thu, May 20, 2010 at 4:17 PM, Steven Edwards wrote: > I've tried with other PNGs before that we've not generated. Take a > third party png, edit the Info.plist and change the icon entry to > instead of pointing at the icns file point at the new Png image. Of > course I've tried this on Leopard, perhaps the behaviour is different > on snow leopard, I don't have a copy of it here. I am pretty sure the png support is iPod/Pad/Phone only. There may be some magic flag to allow OS X to use png rather than icns but I can't find it from google. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Release plans
On Thu, May 20, 2010 at 4:13 PM, Damjan Jovanovic wrote: > Everything in the .png generation looks bog standard, but maybe MacOS > doesn't like our PNG comment. Try remove that ppng_set_text call in > winemenubuilder's SaveIconResAsPNG and see if it helps? I've tried with other PNGs before that we've not generated. Take a third party png, edit the Info.plist and change the icon entry to instead of pointing at the icns file point at the new Png image. Of course I've tried this on Leopard, perhaps the behaviour is different on snow leopard, I don't have a copy of it here. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Release plans
On Thu, May 20, 2010 at 3:44 PM, Steven Edwards wrote: > I have a hacked version in the Bordeaux tree that uses sips to create > icns icons and working Application bundles. If they have time, Austin > or Tom can send it along for your review if your interested. The > 'right' solution would be to figure out how to make them happy with > png's or write a WIC encoder/filter/whatever for icns, I just don't > have the time these days. Without getting off on to a long rant, I > 'hacked' our version call sips on OS X to convert the images to icns.I > was never able to get App bundles to want to play nice with the png > images winemenubuilder spits out but it works most of the time. Since > it's derived LGPL code we are happy to share, though it really is a > hack and I am sure Alexandre would not want it in the tree, even for > the new release. > > Sorry for the double spam, I thought I did not have a copy of the code handy. Here is the hacked patch, it's quite nasty as it forks for every image is processes so it takes a while to generate the icons. There was a bit of a race condition so I further hacked it by sleeping but it got the job done. As I said, figuring out why Appbundles did not want to play nice with the png images would be great. I suspect png image AppBundle support really only works on iDevices and not full OS X and if so, we just need a better way to spitout/convert to icns images. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo wine_menubuilder Description: Binary data
Re: Release plans
On Thu, May 20, 2010 at 3:08 PM, Damjan Jovanovic wrote: > winemenubuilder generates .png only for 24 and 32 bits-per-pixel > icons, all other resolutions get converted to .xpm. I am planning to > change it to make .png's for everything, since thumbnailing .lnk files > requires .png as output, and then keep .xpm only as a fallback when > libpng is not installed and we're not thumbnailing. This should help > you on MacOS too. > > > I have no idea how the other packages built atop Wine behave on MacOS > > behave: > > - Kronenberg's WineBottler > > - doh's WineSkin > > - Macports build > > - CodeWeaver's CrossOver4Mac > > I assume they create nice icons that the user can click after an install. I have a hacked version in the Bordeaux tree that uses sips to create icns icons and working Application bundles. If they have time, Austin or Tom can send it along for your review if your interested. The 'right' solution would be to figure out how to make them happy with png's or write a WIC encoder/filter/whatever for icns, I just don't have the time these days. Without getting off on to a long rant, I 'hacked' our version call sips on OS X to convert the images to icns.I was never able to get App bundles to want to play nice with the png images winemenubuilder spits out but it works most of the time. Since it's derived LGPL code we are happy to share, though it really is a hack and I am sure Alexandre would not want it in the tree, even for the new release. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
South East Linux Fest
Hi, I'm going to be running a both at the South East Linux Fest in Spartanburg SC June 11th-13th. If any wine hackers or lurkers from the South Eastern United States want to come out and help, drop me a note privately. I can't offer much in accommodation but I'll provide beer. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: winmm: Rewrite time.c using ntdll timers
On Tue, Apr 6, 2010 at 6:08 PM, Maarten Lankhorst wrote: > --- > Should fix bug 22252 as a side effect. It should also make it possible to > run our winmm on windows for wave playback because the timers are now using > win32 apis. :) Thanks, I've been waiting for something like this since 0383e4e4990e414a7dcaba51e6b81bf60499944a ;) -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Verbose explanation about the cygwin issue
On Tue, Mar 23, 2010 at 4:17 AM, Peter Rosin wrote: > So, you need to ask yourselves what you want to do. Do you want to > build Cygwin dlls/executables (depends on Cygwin libc) or do you > want to build MinGW dlls/executables (depends on msvcrt)? > > Mixing is not supported, and if you do that anyway with anything > sufficiently non-trivial you get to keep the pieces, so the > suggestion to use -L/usr/lib/w32api -lmsvcrt with the native > Cygwin gcc is not good even if it appears to work. (hmmm, was > that even the suggestion?) I think I missunderstood the original problem with winegcc looking for the entry point but the ultimate problem is still the same which is as you pointed out which is linking to both msvcrt and the cygwin runtime won't work. I think it could work if you don't actually use the system msvcrt but instead use the wine msvcrt which is dependant on the cygwin runtime. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Verbose explanation about the cygwin issue
On Mon, Mar 22, 2010 at 12:47 PM, Steven Edwards wrote: > My thinking was, if we require mingw on cygwin, then that would solve > the winegcc problem and the rest of wine could be built including wine > msvcrt, applications that linked to msvcrt would of course have to use > Wine msvcrt because if they don't then we will get in to the situation > of both c runtimes being invoked which I expect will still not end > well. Sorry I realize that last sentence ran on to hell. What I mean is, on the cygwin build, require mingw to be there for the compilation and invocation of winegcc which is a wrapper around cygwin-gcc. Wine dlls, programs, server, etc all still would be linking to the cygwin1 runtime but would in no way be dependent on Windows msvcrt only Wine's and the environment cygwin1.dll Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Verbose explanation about the cygwin issue
On Sat, Mar 20, 2010 at 2:49 PM, Alexandre Julliard wrote: >> And what about #ifdef __CYGWIN__ ? >> It sounds ugly but ... why not ? > > You can't use #ifdefs in winegcc. I suppose you could try to resolve > __wargv dynamically at run-time. I was wondering if it was possible under current cygwin to still install mingw that was a separate package from the cygwin-gcc. Sorry for not asking sooner but I assume based upon prior emails we are going to end up linking msvcrt and cygwin1? Are you sure this is even going to work? When I've tried this in the past, which was years ago, the applications would either crash or behave unpredictably. I checked the cygwin faq and linking to both msvcrt and cygwin1 was still not supported but perhaps the FAQ is out of date. I am not sure what has changed and have just be cursory following this but it peaked my interest since it was stated that they removed the -mno-cygwin option. Assuming 'bad things' still happen, I was thinking, could we make it work if we linked to msvcrt and then were able to use a wine build of our msvcrt which would forward functionality that it did not implement itself to cygwin1. I guess this is kind of how msvcrt/glibc work on Linux. More assumptions which may not matter but, I could see it still not working due to msvcrt perhaps being a 'KnownDLL' in recent windows (I am not sure if it is or if you can still use your own msvcrt). Also this whole idea would create a circular dependancy because we would have to build wine to be able to build winegcc, My thinking was, if we require mingw on cygwin, then that would solve the winegcc problem and the rest of wine could be built including wine msvcrt, applications that linked to msvcrt would of course have to use Wine msvcrt because if they don't then we will get in to the situation of both c runtimes being invoked which I expect will still not end well. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: dns-sd dll implementation -- Needs work
On Tue, Feb 23, 2010 at 7:08 AM, Gert van den Berg wrote: > On OS X, it would also eliminate the need to install the Windows > version of Apple applications bundled with OS X in order to run things > that uses a single library provided by them. (e.g. Bonjour support in > VLC) Do you really want to run the Windows version of VLC on OS X? I believe there is a better case to be made with Safari/Quicktime/iTunes as I believe they also install Bonjour services on Windows. If you wanted to validate/compare how the native service works verses say a wrapper then it would be of use. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: makefiles: Add some msvcrt imports needed under Cygwin
On Sun, Feb 21, 2010 at 3:33 PM, Alex wrote: >>> -IMPORTS = shell32 user32 kernel32 >>> +IMPORTS = shell32 user32 kernel32 msvcrt Unless something has changed I don't think we want to do this anyway. What we need is something like the EXTRALIBS rule that adds msvcrt if its on cygwin. Take a look at what we do in wininet so that we link to winsock on mingw but use standard sockets the rest of the time. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Intercepting GDI calls
On Mon, Feb 15, 2010 at 4:05 PM, Ove Kaaven wrote: > Sure it might be confusing, because that's not how the logic goes in the > Microsoft world. Over there, the big machine acting as Terminal Server > thing is the server, and the Remote Desktop client, which provides the > actual display, is the client... while on X11, it's the complete > opposite. I'm not going to pretend that it couldn't be confusing. The whole X11 client/server discussion was touched on in the Unix Haters Handbook chapter on X11. I think that reference proves the merit of the argument. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: libpng dependency issue
On Fri, Feb 5, 2010 at 9:54 AM, Vincent Povirk wrote: > It's supported 32bpp with transparency from the start. The full list > of supported writing formats is here: > http://source.winehq.org/source/dlls/windowscodecs/pngformat.c#L680 > > GUID_WICPixelFormat32bppBGRA is the format you want, I think. > > You probably tried to use a format not on that list, which defaults to > 24-bit. I'm not sure what the behavior should be in that case. Thanks, I'll take another look. > That's odd. Both WIC and winemenubuilder appear to be using BGR for > 32-bit pixel formats and informing libpng of this . I don't know where > you could be getting RGB pixels. It was just a thought, as I said, my understand of the graphics manipulation is pretty limited, I just assumed that was the problem due to resulting images. I'll try to give it another shot with this information. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: libpng dependency issue
Hi, On Thu, Feb 4, 2010 at 7:08 PM, Luca Bennati wrote: >> Technically, winemenubuilder should be using windowscodecs for its png >> support, like the rest of wine. I believe Steven Edwards has done some >> work on this. > > Don't know about this. What i know is that currently winemenubuilder shows > this > problem and it's needed to be worked out if you want to support builds on > libpng I was looking in to the overall architectural issues but have not had the time to really hack on it recently. As far as I understand, the current png support in wine's windowscodecs does not support creation of a 32bpp image with transparency, unless I missed some commit messages or totally misunderstood our discussions. I believe from my reading native does support doing the conversions, saving the alpha channel information, applying the masking, etc. I was working on a patch for winemenubuilder so we would at least have that part part done, even if it only spit out 24bpp images without transparency but never got very far with it. If I recall correctly, the current code parses the raw ico bitmapinfo, passes that to libpng, applies the mask and generates the resulting image. I tried a few different ways, using WIC to open a stream to the icon that was then parsed by the icon decoder feeding the png encoder to generate the image. I also tried using the existing parsing system, feeding that to the bitmap decoder then the png encoder and never could get it to work quite right. With the patch I had, the resulting png image was corrupt possibly due to some RGB/BGR issue, I seem to recall Vincent mentioning something about that as well. Also I don't understand all of the magic involved in these operations so I got kind of stalled on it until I am motivated to try to merge my MacOS Application Bundle patch for OS X again. For my own education I want to try to write a test for Windows that calls GdiAlphaBlend on a bitmap image, applies the mask and then uses WIC do the same operation and compare do a comparison. Something could be done based on existing WIC tests. If someone with better understanding feels motivated to do the legwork in WIC, winemenubuilder can be fixed in pretty short order. There is some redundancy in the code because there is an old code path for XPM generation if libpng fails. I don't know if Alexandre really cares about the XPM case, I'd just like to remove it. He did agree that using WIC was the way to go. Just about everything that supports xpm supports png these days. I wasted a lot of time going through mental cycles thinking about how to abstract the icon creation since on OS X (at least on leopard) the icon format used by application bundles is icns not png, so we would either need to have a special case for OS X anyway. I don't think making a generic interface for corner cases like this should be a show stopper. From what I gathered, WIC has this concept of user defined image codecs. I suspect if we suddenly found people bitching at the lack of XPM fallback support, we COULD go through the trouble of being purists and writing a WIC decoder for these non-standard formats but then again, this app is not meant to run on Windows ever anyway so what's the point of being purists? If we want to keep a XPM fallback using the old method, it would be simple enough. As far as the icns case goes on OS X, it would also take a lot less code to just call sips on the resulting png to have it do the conversion to icns for us. I am not even sure if this step is even really required on Snow Leopard, it may actually support using png's for appbundles. When I last looked at the Application Bundle documentation it implied that PNG was a supported format but was not clear if it was limited to the iphone OS. Since my last round of RFCs, submissions and groveling for comment on the direction I was going with Application bundles was met with general silence, I've lost interest again for a while. I'll pick it up again at some point and So again, since this entire email has most likely exceeded the total LOC in required, the simple answer is, I think, even if we fix winemenubuilder to use WIC now, it would result in reduced quality icons until WIC is enhanced due to lack of 32bpp with alpha channel for transparency. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Legal issues with wine development
On Fri, Jan 15, 2010 at 1:41 AM, Benjamin Zink wrote: > I understand you aren't allowed to look at the source code. The question I > have is are you allowed to look at the headers and is an API that's auto > generated from the source ok to look at? http://www.cppdoc.com/ has a > javadoc style mfc api auto generated from the mfc source. Is this an ok > thing to look at? Alexandre will have to correct me if I am wrong on this, maybe the rules have changed or are not clearly defined, this is just my experience working on the wine project. IANAL but here goes: Normally your at the mercy of the license of the SDK or source in question with the understanding that Interface information is not subject to copyright. If you physically copy the source code from a given header to your header it would legally be a violation, but your writing an interface for other code that will be blackboxed. At one wine conference, the rule I heard was, open the header, read the interface, close the file and open your file and rewrite the interface in your own words. Each project seems to have slightly different rules, but this is the standard we've followed forever. These is of course the subject the the EULA of how you got the header. I had patches rejected to the mingw w32api project before where I submitted certain wine headers, the authors offered to relicense under public domain. They were rejected because at the time information was only obtainable via a SDK download with a EULA attached, even though it was very liberal. Since your source is a site on the internet, even if the terms of the MFC source were not pretty liberal, someone else is 'documenting' the interface by publishing it on the web. Since your using this alternative source, that seems to fall under clean-room standards. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: [PATCH] Replace builtin WineFile Execute Dialog with standard RunFile Dialog - try2
damnit. sorry about that, that's what I get for trying to amend. Here
is the correct patch, try 3
On Tue, Dec 29, 2009 at 12:34 PM, Steven Edwards wrote:
> I don't know why this didn't get through, resending from gmail.
>
> This time incorporating (most of) the feedback from Dmitry Timoshkov
> and Paul Vriens and attempting to better match the coding style of the
> rest of the file which is inconsistent as hell.
>
> --
> Steven Edwards
>
> "There is one thing stronger than all the armies in the world, and
> that is an idea whose time has come." - Victor Hugo
>
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
From f9a2429f5b1049309623042e8519ee438cd40ce3 Mon Sep 17 00:00:00 2001
From: Steven Edwards
Date: Mon, 28 Dec 2009 11:44:20 -0500
Subject: [PATCH] Replace builtin WineFile Execute Dialog with standard RunFile Dialog
---
programs/winefile/Cs.rc | 17 +-
programs/winefile/Da.rc | 17 +-
programs/winefile/De.rc | 17 +-
programs/winefile/En.rc | 17 +-
programs/winefile/Es.rc | 17 +-
programs/winefile/Fr.rc | 17 +-
programs/winefile/Hu.rc | 16 +
programs/winefile/It.rc | 17 +-
programs/winefile/Ja.rc | 17 +-
programs/winefile/Ko.rc | 17 +-
programs/winefile/Lt.rc | 17 +-
programs/winefile/Nl.rc | 17 +-
programs/winefile/No.rc | 17 +-
programs/winefile/Pl.rc | 17 +-
programs/winefile/Pt.rc | 22 +
programs/winefile/Ru.rc | 16 +
programs/winefile/Si.rc | 17 +-
programs/winefile/Sv.rc | 17 +-
programs/winefile/Tr.rc | 17 +-
programs/winefile/Zh.rc | 33 +--
programs/winefile/resource.h |3 +-
programs/winefile/winefile.c | 50 +++---
22 files changed, 36 insertions(+), 376 deletions(-)
diff --git a/programs/winefile/Cs.rc b/programs/winefile/Cs.rc
index ad71863..80ddc1b 100644
--- a/programs/winefile/Cs.rc
+++ b/programs/winefile/Cs.rc
@@ -45,7 +45,7 @@ IDM_WINEFILE MENU FIXED IMPURE
MENUITEM "&Komprese...",119
MENUITEM "&Dekomprese...", 120
MENUITEM SEPARATOR
-MENUITEM "&Spustit...", ID_EXECUTE
+MENUITEM "&Spustit...", ID_RUN
MENUITEM "&Tisknout...",102
MENUITEM "Asociovat...",103
MENUITEM SEPARATOR
@@ -150,21 +150,6 @@ IDM_WINEFILE MENU FIXED IMPURE
}
}
-
-IDD_EXECUTE DIALOG FIXED IMPURE 15, 13, 210, 63
-STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU
-CAPTION "Spustit"
-FONT 8, "MS Shell Dlg"
-{
-CONTROL "", 101, "Static", SS_SIMPLE|SS_NOPREFIX, 3, 6, 162, 10
-CONTROL "&Pøíkaz:", -1, "Static", SS_LEFTNOWORDWRAP|WS_GROUP, 3, 18, 60, 10
-EDITTEXT201, 3, 29, 134, 12, ES_AUTOHSCROLL
-CONTROL "Jako &Symbol", 214, "Button", BS_AUTOCHECKBOX|WS_TABSTOP,3, 45, 71, 12
-DEFPUSHBUTTON "OK", 1, 158, 6, 47, 14
-PUSHBUTTON "Zrušit", 2, 158, 23, 47, 14
-PUSHBUTTON "&Pomoc", 254, 158, 43, 47, 14
-}
-
IDD_SELECT_DESTINATION DIALOG FIXED IMPURE 15, 13, 210, 63
STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU
CAPTION "Zvolte cíl"
diff --git a/programs/winefile/Da.rc b/programs/winefile/Da.rc
index ffc7415..385333c 100644
--- a/programs/winefile/Da.rc
+++ b/programs/winefile/Da.rc
@@ -39,7 +39,7 @@ IDM_WINEFILE MENU FIXED IMPURE
MENUITEM "K&omprimer...",119
MENUITEM "De&komprimer...", 120
MENUITEM SEPARATOR
-MENUITEM "Kø&r...", ID_EXECUTE
+MENUITEM "Kø&r...", ID_RUN
MENUITEM "&Udskriv...", 102
MENUITEM "Associer...", 103
MENUITEM SEPARATOR
@@ -144,21 +144,6 @@ IDM_WINEFILE MENU FIXED IMPURE
}
}
-
-IDD_EXECUTE DIALOG FIXED IMPURE 15, 13, 210, 63
-STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU
-CAPTION "Kør"
-FONT 8, "MS Shell Dlg"
-{
-CONTROL "", 101, "Static", SS_SIMPLE|SS_NOPREFIX, 3, 6, 162, 10
-CONTROL "&Kommando:", -1, "Static", SS_LEFTNOWORDWRAP|WS_GROUP, 3, 18,
Re: Building and packaging Wine Gecko
On Mon, Dec 28, 2009 at 2:34 AM, Ove Kaaven wrote: > OK, I've almost got a wine-gecko package built 100% from source, but > there's a problem: the gcc version in Debian's mingw32, namely gcc > 4.2.1-sjlj, apparently miscompiles the wine-gecko 1.0.0 sources, the > resulting Gecko just crashes. (The mingw32 version in oldstable, 3.4.5 > something, compiles it correctly, but I can't reasonably build-depend on > it, as that version is not even in the current stable.) Would it be possible to build it as a winelib application? -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Acting as advisor for wcmd-uplift project?
On Sat, Dec 26, 2009 at 1:57 PM, Erich Hoover wrote:
> Are you using a real cmd.exe or the Wine cmd.exe? I encountered a problem
> at one point with using a real cmd.exe with CreateProcess, I never actually
> finished tracking it down though b/c it wasn't an issue with the
> Wine-included cmd.exe.
I wrote a telnet server that worked on Wine and Windows using
CreateProcess. See if somthing like the following helps
const char *name = "c:\\windows\\system32\\cmd.exe";
const char *cmd = NULL;
if (!CreateProcess((LPSTR) name, // executable module
(LPSTR) cmd, // command line
NULL, // process security attributes
NULL, // primary thread
security attributes
TRUE, // handles are inherited
DETACHED_PROCESS + // creation flags
CREATE_NEW_PROCESS_GROUP,
NULL, // use parent's environment
NULL, // use parent's
current directory
&si, // startup info
&piProcInfo)) {
ErrorExit("Create process failed");
}
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Re: [PATCH] Replace builtin WineFile Execute Dialog with standard RunFileDialog
Hi Dmitry, On Thu, Dec 24, 2009 at 2:21 AM, Dmitry Timoshkov wrote: > Avoiding a needless renaming of ID_EXECUTE to ID_RUN would make the patch > much smaller. Also avoiding useless typedef, making WineFile_OnRun() static, > using correct casts, avoiding hungarian notation and magic flags would make > the patch slightly cleaner. Thanks for the feedback. I'll clean it up per your suggestions though I don't think that renaming ID_EXECUTE is not needless since the dialog containing the word is gone. I think it makes it less trouble if your doing a cursory inspection to make it more consistent. Have a Merry Christmas! -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: winefile - replace Run/Execute dialog with standard Shell32 RunFileDlg
On Wed, Dec 23, 2009 at 1:26 PM, Paul Vriens wrote: > Isn't shell32 already available (it's imported, see Makefile.in)? If so a > GetModuleHandleW() would suffice. Your right. Looking closer it looks like I didn't follow the Tab abuse that's used in the rest of the file either so I'll resubmit with both of those changes. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Parser for cmd language?
On Sat, Dec 19, 2009 at 12:33 PM, Wolfram Sang wrote: > Has also relicensing such a spin-off been discussed? (Don't want to > impose anything, I'm just curious here.) Not specifically the case of cmd but we've been discussing it regarding large parts of the project as a whole. A dual or tri-license solution much like what the Mozilla project does is preferable but nothing is set in stone yet. If there is a legitimate need for any part to be relicensed most of the developers are accommodating. Email me privately if you have a specific request. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Parser for cmd language?
On Fri, Dec 18, 2009 at 8:01 PM, Dan Kegel wrote: > Oh, and http://ss64.com/nt/syntax.html seems like a nice summary > of the language. This suggestion will most likely get null'd as it has before but since there are still patches accepted by ReactOS developers from time to time, it would seem to make more since to me to just prepackage a winelib build or binary build of their cmd.exe somewhere. It's mostly feature complete and is derived from FreeDOS command.com and a large chunk of the development work on it was done by former CodeWeaver Eric Kohl. We (reactos developers) toyed with the idea of spawning some of the subprojects off in the past, so perhaps we could create a new sourceforge project, something along the lines of FreeCMD and move the project and revision history there. Linking to it as a separate project package is not that much of a stretch from how we do things with Gecko. Having a comprehensive test suite written for the scripting language makes sense but the duplicated effort to re-implement the whole app never has given there are already shared tools in the winehq tree such as regedit and taskmgr unless you are ready to propose that they be ripped out. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: weird and funky things happen when viewing guimark in ie6 in wine...
On Sun, Dec 13, 2009 at 10:57 PM, Austin English wrote: >> Building font metrics. This may take some time... >> Font metrics: 0.0% done >> ... >> and the whole long font metric rebuilding process, which should >> never be happening anymore for local X servers (right?). > > It still occurs on OS X (last I tested). I think that it may be > related to the DYLD_FALLBACK_LIBRARY_PATH problem. Yes it still happens on OS X unless you hack your environment though I've not seen it on Linux in forever and a day. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: How does --with-wine64 work?
On Mon, Dec 7, 2009 at 9:30 PM, Steven Edwards wrote: > This looks similar to the cross-compile build for mingw where you need > a checkout with the normal tools built for your host and then another > checkout for your target. You then run and point the target configure > at the host wine path to get the host tools. Doh I read that wrong. You had it right if it follows the same structure as the mingw port. No idea, I'll try a build here in a bit -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: How does --with-wine64 work?
On Mon, Dec 7, 2009 at 7:44 PM, Austin English wrote: >> checking for the directory containing the Wine tools... configure: error: >> could not find Wine tools in ~/wine64/ > ~/wine-git/configure --with-wine64=~/wine64/tools/ > ... > checking for the directory containing the Wine tools... configure: > error: could not find Wine tools in ~/wine64/tools/ > > What am I missing? Perhaps it needs to be installed somewhere first? This looks similar to the cross-compile build for mingw where you need a checkout with the normal tools built for your host and then another checkout for your target. You then run and point the target configure at the host wine path to get the host tools. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Please Review - Revised OS X Application Bundle patch
On Mon, Dec 7, 2009 at 12:46 PM, Mike Kronenberg wrote: > This can be easily done, I've integrated lately similar functionality in > WineBottler. > If You already have the png only the sipping part of this little script is > needed. > > createIconsFromExe.sh Oh sure, we can do it now, but like I just said to Joerg, just because we can do it now does not mean that Alexandre will let us do it now. Winemenubuilder really needs to be cleaned up and abstracted as we go along in this process. 1. Generic App Bundle Support (my patch does this) 2. Pretty Icon support (next on the list) 3. Associations At each step along the way, Alexandre is going to want it to at least be cleanly separated so it can be re-factored. Just look at how I had to hook in to the main winemenubuilder file and bail out on unsupported features. It's intimately tied to xdg which is good for the Linux side but sucks for us, and what if tomorrow someone invents something better on Linux for menus or associations? It really needs to be abstracted the right way. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Please Review - Revised OS X Application Bundle patch
Hi Mike, On Sat, Dec 5, 2009 at 2:43 PM, Mike Kronenberg wrote: I cut out the rest of the discussion for the moment as I am short on time and it's clear we all have a different philosphical POV on how Wine should behave. I'll leave it up to Alexandre to decide as far as my patch goes for app bundles. I think Wine users on OS X will attribute the bad behavior you describe to being part of the pain of dealing with Windows apps. At least when I was supporting CrossOver on OS X, most of the apple users I spoke with were more accepting of the glitches and limitations as opposed to how they would expect normal Mac software to behave. Maybe times I heard something along the lines of "it's ok, this is a windows app I am dealing with". > But what about these: > ~/.local/share/applications > ~/.local/share/desktop-directories > ~/.local/share/icons > ~/.lcoal/share/mime > Can I somehow disable them or move them inside the prefix? I know the concept > of "share", but since I started with answering mails about how to completely > remove wine the list of files and folders to search and clean is growing > constantly. This is xdg-associations winemenubuilder is trying to handle. My patch disables this behavior on OS X until we properly fix associations. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Please Review - Revised OS X Application Bundle patch
hat can parse png natively however our current windowscodecs.dll lacks 32bit w/Alpha channel support so it would be a step back for me to go ahead and just plug in WIC support. The underlying dll must be fixed first. > What I visually "see" is what existed in MS-Win3.x: Program > manager windows that grouped together all the related icons. > They still exist: just visit C:\users\me\startmenu\x\y\z with > the file manager. These days you typically access the icons only > via the "Start" menu. > > Kronenberg's distribution presents itself like win3.x: 3 icons > in a window: one starts Wine, an other is the help file. But this > window comes from a .dmg, while a .app presents one single icon. I am not sure I follow, I've not looked at his distribution lately but it seems wrong. Wine should be transparent to the user with the exception of the documentation. >>The idea is that users should NEVER need to mess with >>WINEPREFIX or WINEDEBUG settings EVER. > Agreed for WINEDEBUG. I disagree for WINEPREFIX. Otherwise you could > just hard code it to "$HOME/.wine". For a WINEPREFIX != "~/.wine" to > come into existance at all, the user MUST have set it to something else. > It does not appear out of the blue. > > There is a need for different WINEPREFIX and your (or any) solution > must provide a way to access it. E.g. several Wiki pages recommend > installing DirectX9 into a distinct WINEPREFIX, for good reason. > Apps that depend on native DX9 should run in this WINEPREFIX. Well maybe I should have been more clear. They should NEVER need to mess with WINEDEBUG unless there is a problem. My code takes in to account a different WINEPREFIX. That variable gets set if they install using a different prefix other than ~/.wine. winemenubuilder, *.desktop files and my app bundle patch look for that variable and set it accordingly. It's up to the user to figure out how to install using another WINEPREFIX until we have a better solution in place. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Please Review - Revised OS X Application Bundle patch
Hi Jörg, Thanks for the questions. Hopefully I can provide good answers. On Fri, Dec 4, 2009 at 10:33 AM, wrote: > + * NOTES: An Application Bundle generally has the following layout > + * > + * foo.app/Contents > + * foo.app/Contents/Info.plist > + * foo.app/Contents/MacOS/foo (can be script or real binary) > + * foo.app/Contents/Resources/appIcon.icns (Apple Icon format) > + * foo.app/Contents/Resources/English.lproj/infoPlist.strings > + * foo.app/Contents/Resources/English.lproj/MainMenu.nib (Menu Layout) > > > Could you please comment on why you think that using a .app is the > right approach? (please explain the goal: provide desktop icons?) > What do you plan to put into that bundle? > What would the menu be? (Is there one at all?) The Application bundle provides a mostly 1 to 1 mapping for any *.lnk that is generated and processed by Wine Menu Builder. In the case of my test app I am using Microsoft PowerPoint Viewer 2003 and am able to drag the resulting .app to the dock, desktop, or anywhere. > As an alternative, I've been creating .command files, as explained > in the FAQ http://wiki.winehq.org/MacOSX/FAQs > They seem conceptually simpler yet provide what you'll find > in the xyz.desktop file that Wine produces on Linux: It is conceptually simpler but does not offer the rich features app bundles gives you. > - Icon I don't know how to make the .command file accept a generate icon in a automagic fashion. I think there was some hfs meta data magic involved. Not a big deal but just dumping the generated icon and editing the plist is the standard way to go. > - Terminal window that shows Wine's log and I/O from application. > Where does such output go in the .app case? It goes to the Console Messages viewable with the Console application. You can run the bundled script directly as it's just a bash script if you need to debug but the point is to hide the terminal IO from the user. > - file name > - Change Directory to app's directory (or any other) > It does not depend on wine start /unix > Isn't that missing from your patch: > + fprintf(file, "#!/bin/sh\n"); > + fprintf(file, "WINEPREFIX=\"%s\" wine \"%s\" %s\n\n", > + wine_get_config_dir(), path, args); > This information is present in the .desktop files > - Move the icon anywhere you like and click to start it. > There's no dependency on Applications/ or any other setting. > - Easily modified by the user to change WINEPREFIX, add WINEDEBUG > or whatever -- if needed at all. This is the same way as the *.desktop files on Linux. No need for start /unix. The idea is that users should NEVER need to mess with WINEPREFIX or WINEDEBUG settings EVER. If they do then something is wrong. It should be seemless. > You'll remember that I presented my approach on 2009-09-14 in this list. Yes. I disagree with the resource fork hackery you were doing. It's not that way any other application vendor bundles an app on OS X. Using an application bundle, it would be possible for a third party vendor to take a full install of Wine, the vendor application and a custom prefix and tie the entire thing together in one bundle as a winelib application. *.command files don't allow that. > I was wondering whether Wine should create such xyz.command files on MacOS > instead of the xyz.desktop ones. They are so close to each other. > > Perhaps it is precisely that additional Terminal.app window that > you or other Mac users might dislike? > (I've not investigated whether there are "hide" or "auto-close on exit" > properties that could be set.) Yes the Terminal window and the lack of ability to make a private Wine. Let's say I write my own Win32 program called Doodles and its highly tied to Windows and I don't want to deal with a source port. Using app bundles I can take doodles.exe, a private install of Wine, the needed Frameworks and icons, tie it all together in a Doodles.app and give that to users. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Please Review - Revised OS X Application Bundle patch
Hi, If any of the OS X hackers have time, could you guys take a look at the following patch? I'd like to get it in to move on to more interesting stuff like the icon generation cleanup in winemenubuilder using windowscodecs.dll, OS X association support and perhaps even proper dock integration. I've been testing this with the PowerPoint 2003 viewer and it works for me. I'd be interested in hearing if anyone has trouble with other applications. You need to have Wine installed somewhere in your path or you will need to manually hardcode the path to your wine executable in the script generator just like with the menu builder on the linux side. I don't like the amount of #ifdef'ing I had to do but didn't really see a better way. I know before Alexandre will accept he most likely will want me to - Cleanup comments a bit. - Maybe shorten some of the variable and function names So I am looking for any other feedback you have. Documentation on bundles can be found at the following location http://developer.apple.com/mac/library/documentation/CoreFoundation/Conceptual/CFBundles/Introduction/Introduction.html Changelog: Implement Application Bundle support for OS X using the CoreFoundation to generate Information Property Lists Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo appbundle2.diff Description: Binary data
Re: My script for doing testing
On Wed, Nov 25, 2009 at 5:48 PM, Austin English wrote:
> Sure, that would be an option if the system has e-mail configured, but
> since I use webmail, I went with the 'sit and wait' method. For other
> projects that script would obviously need a different strategy (though
> I don't other projects are running winetest.exe daily ;-)).
Having the private vncserver or Xnest session is more important than
the polling method.
You should be able to turn your script in to a proper service without
much trouble, the following psudo-init script is a snippet of the
serivce I wrote.
start()
{
echo -n $"winecis spam"
/usr/bin/vncserver -geometry 1152x900 -depth 16 :$DISPLAY >>
/var/log/vncserver.log 2>&1
doaustinswinecismagic
RETVAL=$?
echo
[ $RETVAL = 0 ]
return $RETVAL
}
stop()
{..}
restart()
{..}
etc,etc...
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Re: My script for doing testing
On Wed, Nov 25, 2009 at 5:21 PM, Steven Edwards wrote: > It would be nice to dummy email account subscribed to the commit > messages that it could poll to trigger the checkout, build, test > cycle. > > To make a Continuous Integration Service around it it should run as a > background process under another user out of init in a Xnest/VNC > session. I am thinking something like a winecis user which would run > these scripts, fetch and the Xnest session as a service we could call > winecis. > > I did something similar recently for a stupid java service that had to > have an interactive gui. Thinking about it a bit more, I guess the email thing is kind of redundant since git can poll more often. I guess it really depends on how many build agents you want to have hanging out hammering git. To you want them to hammer git or hammer your mail server? -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: My script for doing testing
On Wed, Nov 25, 2009 at 12:08 PM, Austin English wrote: > The other neat thing is that it will run git fetch in a loop every 30 > minutes (again, overridable), so that you can run it in the morning > while waiting for AJ to commit. Once commits are made to the git > master branch (but not stable), the script will kick into motion. It would be nice to dummy email account subscribed to the commit messages that it could poll to trigger the checkout, build, test cycle. To make a Continuous Integration Service around it it should run as a background process under another user out of init in a Xnest/VNC session. I am thinking something like a winecis user which would run these scripts, fetch and the Xnest session as a service we could call winecis. I did something similar recently for a stupid java service that had to have an interactive gui. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: today's git broke winetricks gecko :-(
On Mon, Nov 16, 2009 at 12:58 PM, Jacek Caban wrote: > You should understand, that we don't want users to have problems due to > *lack* of Gecko. Any solution like moving installation to winecfg means that > most user (at least these, who don't get Gecko from their distro packages) > will have this problem. You also didn't give me any single good reason to > not install Gecko properly. Instead you just said that you pollute winetest > results with your bad configuration. Isn't winetest web configured to reject certain classes of test results already? I seem to recall Alexandre adding some magic to winetest and the site to reject reports or flag them if they were with a sha1hash that did not match a git revision. Could we not do something like this with gecko? If it's not installed then just ignore those results? -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: today's git broke winetricks gecko :-(
Hi Jacek, On Mon, Nov 16, 2009 at 10:16 AM, Jacek Caban wrote: > Did you read the page from the link that is on the dialog informing about > missing Gecko? I've been kind of following this thread and see where Jörg is coming from. I don't think the argument about broken wine due to missing gecko makes much sense given the way we have other soft dependencies that can be missing if you build Wine yourself. A good example is the xml or opengl libraries. It's possible to have a working wine for specific needs without this package. If we are going to require this package for every wine install then I would argue we should not have any other soft dependencies either. If a packager has not packaged Gecko or a hacker has built from source it seems like winecfg should be invoked when a new prefix is created rather than prompting for the download. Maybe for the general usage case we should do it anyway. Alternatively, if we are going to have this hook in here to satisfy this dependency during prefix creation due to packagers not following a required guideline, maybe a little public ridicule will force them to fix the package. Something along the lines of 'your version of wine does not contain the gecko package, please contact the package maintainer and inform them about this issue' or something and let it proceed to download at least. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: [PATCH 02/16] [WinMM, MMSystem]: use the new 16=>32 thunks for Aux driver type
On Thu, Oct 22, 2009 at 4:09 PM, Eric Pouech wrote: > 0 files changed, 0 insertions(+), 0 deletions(-) The winmm win16/32 separation has finally collapsed in on itself and this is the resulting Einstein-Rosen bridge. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: SCSITaskDevice vs our own driver
On Sat, Oct 17, 2009 at 12:39 PM, Alexandre Julliard wrote: >> 1. Use the SCSITaskDevice interface. This is a CFPlugIn object provided >> by the driver (it's like a COM object). We have to get exclusive access >> (this requires all the handles to all device files to be closed, and the >> disk unmounted), and then we can send whatever SCSI commands we like. > > I don't think we can realistically require the device to be unmounted. > Most apps will want to check for files too. If that only leaves option 2. which would require the C++ driver, can or should it be hosted on winehq in another git tree? I am sure you would not want to keep it in the main wine tree but if it was hosted somewhere else on Winehq then we could package it with the Wine bundle. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: [2/2] ntdll: Implement FILE_ATTRIBUTE_HIDDEN and FILE_ATTRIBUTE_SYSTEM support (take 6)
On Tue, Oct 6, 2009 at 10:20 PM, Dan Kegel wrote: >> Your code handle different parameter for the attr functions. >> Is it possible, that code, which is compiled for one ABI version can >> call the implementation of the other ABI version? > > Not sure I follow. Can you rephrase that? I don't know if this is what Detlef means but I think the attr functions and structures differ slightly on other Unixen. At least I am pretty sure they differ enough on OS X from Linux or Solaris to cause problems. I have not looked at the recent iteration of the patch so if you already account for what I am saying, please send this message to the Null device. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: winex11: add alternative header
2009/9/19 André Hentschel : > Thanks for the hint, i had this construction from > http://www.winehq.org/site/docs/winedev-guide/porting (which might be > outdated) > ill send a try 2 Yes I think the guide is wrong or at least misleading. If the #elif case is there its not very common, at least in all the header patches I've ever submitted for porting related issues. I've seen it used plenty of times like the guide says for checking differing implementation of functions and the like. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: porting winetricks to windows
On Sat, Sep 19, 2009 at 12:34 PM, Dan Kegel wrote: > After a while of writing special purpose tool-install-scripts > that would work on either wine or windows, I realized that > I really just wanted winetricks to be my tool install script, > and that it should run on windows. i.e. if you want firefox > on windows or wine, you should be able to do > "sh winetricks -q firefox" and have it appear. Likewise, if > you happen to need the Windows 7 SDK for something > you're building, you should be able to say "sh winetricks -q psdkwin7" > and have it appear, no questions asked. (Assuming > on windows that you have cygwin installed, of course.) I would try to make it supported by default under msys. Cygwin has always had a bloated POS installer and we should not need any other unixism other than bashness. Actually, come to think of it, the best supported platform for it would be msys-git. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: winex11: add alternative header
2009/9/18 André Hentschel : > this is my first patch to autoconf-stuff, please tell me if i did something > wrong > see also Bug 20070 I expect It should actually not look like the following > #ifdef HAVE_X11_EXTENSIONS_XF86VMODE_H > #include > +#elif defined (HAVE_X11_EXTENSIONS_XF86VMPROTO_H) > +#include > #endif and instead like this: #ifdef HAVE_X11_EXTENSIONS_XF86VMODE_H #include #endif #ifdef HAVE_X11_EXTENSIONS_XF86VMPROTO_H #include #endif Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: How I create wine app launcher icons on the Mac
On Mon, Sep 14, 2009 at 5:33 PM, Steven Edwards wrote: > Right but what happened to the png image? OK so I looked at it a bit more in depth and understand what your going for now. So you are embedding the png as a resource fork of the png image but then using the png as a script. You kind of lost me before but it makes sense now. It's creative but not the correct way to do what we want. All that really needs to be done to fix the patch I have is to convert the raw C io-ops to use the Carbon functions for writing out the plist and add a helper to function do the conversion from png to icns. I suspect we might be able to go from png to tiff to icns using OS X builtin tools and spawn* to do the magic. At the worst case we need to write a helper function to convert the format. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: How I create wine app launcher icons on the Mac
On Mon, Sep 14, 2009 at 5:33 PM, Steven Edwards wrote: > Do you mean >> ? wouldn't the > just overwrite the foo.png? Sorry for the noise, I hit send too soon. I mean don't you mean >> rather than just > which would just overwrite the icon you just converted. >> "Opening" this icon will launch a Terminal where all logs will go. >> Optionally you may use Cmd-I(nformation) to disable the display of the >> .command suffix in the finder (unless forced globally). Wine's X11 window >> opens above the Terminal window. > > Using the sample.command or whatever is there a way to always hide the > terminal? What I mean here, is there a switch or resource fork or xattr you can set that implies Cmd-I for this given *.command? I mean, I am sure we don't want to try to enforce that for all other *.command scripts, just ones we create. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: How I create wine app launcher icons on the Mac
Hi, On Mon, Sep 14, 2009 at 1:13 PM, wrote: > On Linux, I have been using .desktop files that freedesktop defines to keep a > directory full of icons. They all launch Wine applications. Often enough, > these desktop files are initially create by Wine in > ~/.local/share/applications/wine/..., along with the icon files in > ~/.local/share/icons/. I wrote a patch to create .app bundled is winemenubuilder that was rejected because it needs to be converted to use Carbon api's for creation and editing of the *.plist files. I think its a better approach/framework because it allows you to have, resource data, multiple icons, and perhaps the ability to add drag/drop to the helper. I am not sure I am following this. > Here's how I now have app launcher icons on the Mac: > > sips -i ~/.local/share/icons/foo.png --out foo.png > # sips -i converts and *additionaly* adds icon resource to file > # Alas, sips does not understand .xpm > cat sample.command > foo.png Do you mean >> ? wouldn't the > just overwrite the foo.png? > # > overwrites contents but keeps resource fork > mv foo.png ~/Desktop/foo.command I guess the resource fork is contained in a xattr right? > # .command is the finder's suffix for executable shell scripts > chmod a+x foo.command Right but what happened to the png image? > sample.command contains: > #!/bin/sh > cd /User/me/xyz && WINEDEBUG=-gsm WINEPREFIX=$HOME/.wine exec wine xyz.exe > > Afterwards you edit foo.command and change the directory, environment > variables and executable names to meet your needs. Be careful to use an > editor that keeps the resource fork. > > "Opening" this icon will launch a Terminal where all logs will go. Optionally > you may use Cmd-I(nformation) to disable the display of the .command suffix > in the finder (unless forced globally). Wine's X11 window opens above the > Terminal window. Using the sample.command or whatever is there a way to always hide the terminal? > I wonder whether this functionality could be somehow integrated into the git > (winemenubuilder?), or whether developers believe this should be left to > "surrounding" projects like Darwine. See this patch http://www.winehq.org/pipermail/wine-patches/2009-July/076251.html > What do you think? I think somebody that is more familiar with Carbon should adopt my patch =) -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Recent ntdll performance information patches
Since the last few rounds of patches to NtQuerySystemInformation I am now getting this error when trying to build with llvm-gcc from the latest Xcode nt.c: In function ‘NtQuerySystemInformation’: nt.c:1012: error: ‘struct _SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION’ has no member named ‘liIdleTime’ nt.c:1013: error: ‘struct _SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION’ has no member named ‘liKernelTime’ nt.c:1014: error: ‘struct _SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION’ has no member named ‘liUserTime’ -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: configure: Detect and use tools executable extensions for makefiles.
On Thu, Aug 27, 2009 at 9:01 AM, Steven Edwards wrote: >> I am using mingw, msysgit, msys, and some GnuWin32 packages, so it is >> possible that it is a configuration issue. I'll retry with only mingw >> and msys. I don't think they provide Flex and Bison though. > > No they don't, I've always had to search for the msys/mingw > developer/dtk packages or use the GnuWin32 ports. I'll see if I still > have a windows box with a mingw runtime installed to look myself. I just checked and can confirm it does seem to require the exe suffix now. I am not sure when that changed. I've not had time to test your patch but it looked good, I'll try to make more time to recheck if Alexandre commits it. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: configure: Detect and use tools executable extensions for makefiles.
On Wed, Aug 26, 2009 at 10:52 PM, Dylan Smith wrote: > I don't know if this is new behaviour. I do remember having trouble > building on windows before, so I gave up and tried cross compiling, > which now works without errors (no -k option needed for make). > > I am using mingw, msysgit, msys, and some GnuWin32 packages, so it is > possible that it is a configuration issue. I'll retry with only mingw > and msys. I don't think they provide Flex and Bison though. No they don't, I've always had to search for the msys/mingw developer/dtk packages or use the GnuWin32 ports. I'll see if I still have a windows box with a mingw runtime installed to look myself. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: configure: Detect and use tools executable extensions for makefiles.
On Wed, Aug 26, 2009 at 2:21 PM, Dylan Smith wrote: > When compiling Wine on windows, the non-script tools will have an .exe > extension, but the makefiles assumed that the tools never have an > extention. Naturally this caused problems with the build, causing it to > fail on Windows. > > Please re-run autoconf to update the configure script. > --- > Make.rules.in | 21 +++-- > configure.ac | 9 + > 2 files changed, 20 insertions(+), 10 deletions(-) I've never had a problem building most of Wine with cygwin or msys+mingw before. Is this new behaviour? -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Linking a winelib application with a windows dll
On Sat, Aug 22, 2009 at 11:17 AM, Juan Lang wrote: >> 1) Creating a vendor.def file doesn't work. The resulting file has an empty >> EXPORTS section: >> >> winedump spec vendor.dll >> winebuild --def -E vendor.spec -o vendor.def > > That seems to mean winedump isn't parsing this right, or that it truly > has no exports. You want to debug winedump, perhaps by adding the -v > flag to winedump. You can use something like dependancy walker to verify the function names that it exports. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: oleaut32: Dynamic invocation for x86
On Fri, Aug 21, 2009 at 1:42 PM, Juan Lang wrote: > Ah, fair enough, and clearly oleaut32 belongs in that category. Thanks. I should have said Windows as technically mingw is still __GNUC__ but you got the idea. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: oleaut32: Dynamic invocation for x86
On Fri, Aug 21, 2009 at 12:31 PM, Juan Lang wrote: > We don't protect by __GNUC__ for any of our other assembly either, > even though it all uses GNU assembly syntax. So personally I think > that part's okay. There are a few instances of it, at least in code we care about sharing with a mingw build sedwa...@sedwards-desktop:~/source/wine$ find -name *.c | xargs grep "(__i386__) && defined(__GNUC__)" ./libs/wine/port.c:#if defined(__i386__) && defined(__GNUC__) ./dlls/ntdll/large_int.c:#if defined(__i386__) && defined(__GNUC__) ./dlls/kernel32/instr.c:#if defined(__i386__) && defined(__GNUC__) ./dlls/winex11.drv/dib.c:#if defined(__i386__) && defined(__GNUC__) ./dlls/winex11.drv/dib.c:#if defined(__i386__) && defined(__GNUC__) ./dlls/ddraw/device.c:#if defined(__i386__) && defined(__GNUC__) ./dlls/ddraw/device.c:#if defined(__i386__) && defined(__GNUC__) -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Appinstall testing guide up on the wiki
Hi Austin, On Sat, Aug 15, 2009 at 2:58 PM, Austin English wrote: > It handles the process of automatically downloading, running, > verifying and testing various applications under Wine, against > previously verified Windows behavior. It can test for regressions of > popular applications/features, as well as making sure bugs aren't > subtly fixed. The wrapper script handles fresh WINEPREFIX's, > winetricks dependencies, timeouts of runaway/hung tests, and parsing > of the output logs. I've just given this a cursory look but I like it. I think what we need to do to insure that its used and that scripts are kept up to date is encourage wine appdb submission of scripts for applications that are listed as gold/platinum. My thinking is that if we get good scripts in appdb then the app maintainer wont have to carry all the work of regression testing it at each release. If someone finds a regression they can use the script to save time as they rollback and test prior winehq releases and work with that app advocate to track down the issue. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: mp3 update
On Wed, Aug 12, 2009 at 6:30 PM, Aric Stewart wrote: > Well the main advantage I can see is that we are able to have mp3 support > without adding a new library dependency. This will be especially useful for > platforms other than Linux where libmpg123 is not present. Such as the Mac. Heh yeah I didn't think about this. > There is no technical or licensing reason we would have to link to the > native library. > > We could make a configure parameter that either links native existing > libmpg123.so or builds the independent builtin version. It's not worth the trouble. In fact what your doing sounds perfect now that I've had a chance to think about it. We already pull in too much crap for external libraries. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: mp3 update
On Wed, Aug 12, 2009 at 4:34 PM, Chris Robinson wrote: > Personally, I'd think linking libmpg123 would be a better option, instead of > duplicating it. It would allow Wine to be updated when the lib updates, > instead of trying to keep up with changes, and avoid duplicating > functionality. Right. Is there an particular reason we can't dlopen the native library? Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
On Mon, Jul 20, 2009 at 2:48 PM, Emmanuel Maillard wrote: > As answered in private email (sorry, just for an short anwser for list) > If we plan to bring freedesktop to Mac OS X, yes we need an external > application > that doesn't have to go to winehq, winehq doesn't have application for Linux > distribution that doesn't be xdg-compliant (if any) ... Yes it pretty much depends on the portland tools to already be ported. I agree and don't think its worth our effort to try and support our own helper to parse or convert xdg when the bundle format is so simple. We can reuse a lot of the internals of xdg support in the menubuilder to convert icons and spew out data the plist's need without having to try to teach OS X to support a non-native format. > In case of generated *plist just add you WINEPREFIX in your file. > In case of WineHelper you can define WINEPREFIX in applications Preferences. > (just need to be review to be more flexible) I didn't think about this. Yes it would be possible to define the variable there. >> If its truly a single user system then prompting one time for a >> location, either /Applications or ~/Applications seems like the right >> method to me. > > Or /dev/null for command line wine users ... Heh yes perhaps their should be a variable to tell it to not generate a menu at all. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Status of the Status pages?
On Tue, Jul 21, 2009 at 8:02 AM, Scott Ritchie wrote: > My overall goal for them is to replace them with dynamically generated > statistics based. Some possible things to use: > - Bugzilla stats, especially a chart of open 1.2 bugs and total New bugs > - Winetest coverage (based on gcov) > - Winetest results > - Austin's test suite results (especially if we get a good number of > tests for apps that aren't yet working) > - AppDB stats > > I'll work on some of this after I go through the rest of the WineHQ.org > pages (eg the About page), which also need cleanup. I would add it would be nice to show how much of the API is documented vs exported. We could keep a similar structure to the page we have now but pull data from http://source.winehq.org/WineAPI/ and show how well documented the functionality we export is covered. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: FW: Re: please reduce the four registrations on the single winehq.org site.
On Mon, Jul 20, 2009 at 5:21 PM, Sparr wrote: > Was the contempt for OpenID in general, or the idea of using an > existing third party as an OpenID providers? Although it would be > against the spirit of OpenID, it would be possible for one WineHQ > service to provide OpenID only to other WineHQ services, and for them > to only accept an OpenID from that particular WineHQ provider. This > would be no better than other single-sign-on solutions, but there are > a lot more open source cross-framework implementations of OpenID > available than for most other solutions. I think its best if the google contingent answer that. Dan had some issues with it I think but I don't know if any of them are still applicable. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: FW: Re: please reduce the four registrations on the single winehq.org site.
On Sun, Jul 19, 2009 at 10:35 PM, Scott Ritchie wrote: > Mozilla are farthest on the game here, as they were working on writing > some of their own custom stuff based on OpenID, however that then deals > with the need of having each app support an OpenID login. > > I'm not sure if it's a good idea, but there may be some merit in having > one of the accounts function as an OpenID Provider and then have the > others be able to link to it (but still be "separate accounts"). After > that it's just about being able to login by OpenID rather than have a > single account moving across each place. Based upon my recollection there was a lot of contempt for OpenID at the last wineconf. Maybe the situation has changed recently... Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
On Sun, Jul 19, 2009 at 12:23 PM, Emmanuel Maillard wrote: > But it's an external appplication, your desktop environment, that handle > *.desktop file; wine just generate them... As per the private email I sent. I could see that working if we can convince Alexandre of the need of an external helper application for OS X. Keeping the existing winemenubuilder code mostly as is and having it write xdg menus and associations would be pretty simple. We could just change a few lines to have it write xdg in ~/Library/Application Support/Wine/WineMenuBuilder > So don't choose ~/Applications but : /Applications/Wine or > let's the user to choose if want an Applications folder in is Homedir. The reason for using ~/Applications as opposed to /Applications is that Wine has no knowledge or real support for multi-user prefixes. Each .wine being local to the user that creates it will have their own applications, etc. If we write the menus to /Applications and another user logs in then they won't be able to run those applications. > False with WineHelper : > User opens HomeDirectory or Finder > User goes to desired path and selects Winword.exe (.msi, .lnk) > (Helper start if needed) Winwords start > as intuitive as your Case 2 ... If the associations for Wine and the given type are set right (*.exe, *.msi, *.lnk, *.whatever) then I could see this working at least for a default WINEPREFIX. All of that assumes the executable and or links are easy to find and we have the virtual start menu. Again the problem I see is if your setting associations for installed applications it makes supporting a given prefix not really possible. > WineHelper is Open Source so you can add any features you want, fork it, > ask write access to Darwine CVS, send me patches (i must still have write > access) I don't really know what I want besides a simple way to access installed applications. Bundles give me that, though I can see how a helper might have some advantages. Honestly though, I don't have the free cycles to write one. I've spent over a month or two just researching Bundles vs Finder Aliases and HFS resource forks trying to come up with a seemless solution and you see how little I've written. > So please just use /Applications or ask the user if he want an a new > directory > in his Homedir. If its truly a single user system then prompting one time for a location, either /Applications or ~/Applications seems like the right method to me. For me though it all comes back down to supporting future design like better prefix support while making it work today. I'm going to revise my patch to support direct execution of shell scripts and clean it up so that its not such a hack with the existing xdg code an resubmit. Assuming Alexandre accepts that, there is nothing stopping us from developing something better down the road but for now, users will have a Wine they can actually use once they have apps installed. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
On Sun, Jul 19, 2009 at 8:10 AM, Emmanuel Maillard wrote: > Just few remarks about your patch : > - why you didn't use CoreFoundation API (plain C and already used in Wine) > insteed of fprintf to generate Info.plist ? I didn't see which functionality to call to generate the plist's in C. Could you point me to the api's that are of use? > - you don't really need a Carbon launcher. Just a plain shell script in > MacOS for executable et voila ... > (sample joined, just edit MacOS/Notepad to set correct path) Very Nice! I must have overlooked this when I was exploring other problems like getting the xattr stuff right in the plists. I'll change my patch to reflect this for the first iteration. I still believe a future version is going to need some sort of helper application if we ever want to actually interact with a running instance for example, sending a quit message or cycling through active windows, etc. > IMHO In a more general way, it's not a good thing to touch user directory > without letting him decide. > For application generated file you should used ~/Library/Application > Support/Wine > (see : > http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html#//apple_ref/doc/uid/20002282-BAJHCHJI) I see that but that implies a separate application to manage installed Wine programs like you state below, like WineHelper. This is going to be very hard to get in to stock Wine given our limitations on not using Cocoa > And at last, an NSStatusItem seem's a better choice to me for a wine > application starter, instead of fake app bundles. > Just generated description plist (dictionnary with app name, full path, > arguments, and icon path ... and what ever you want) in > ~/Library/Application Support/Wine/WineMenuBuilder > and lets Helper application (your Bordeau's helper, WineHelper, or Mike > Kronenberg one's) deal with theese files as they want. Perhaps but I don't think so. Allow me to present things from the user perspective. I think writing to ~/Applications/Wine is OK and does not violate HIG as installing an application under Wine (to me at least) is analogous to running a mpkg that does not prompt where to install. The user clearly wants to install the application if it gets to the point of generating the shortcuts and bundling it up. Having some sort of helper application application that manages it own internal list of menus seems to imply multiple operations and steps that don't seem correct at least to me. Here is the work flow I see Case 1. With WineApp Helper User opens HomeDirectory or Finder User goes to /Applications or ~/Applications and starts the Wine helper User then selects Winword from the list of known installed Applications Winword Starts or Case 2. With wine app bundles User opens HomeDirectory or Finder User goes to /Applications or ~/Applications and selects Winword Bundle Winword Starts The second case seems simpler and more intuitive. Now I could see a third case that would kind of give you the best of both worlds. Assuming your helper application was part of the Dock, you could have it act as a special launcher that expands like the way the Documents and Downloads menu's do and the user could select a given Windows application from there. Assuming that's the way it behaved we could have something like the following: Case 3. User navigates to Dock and icon for Wine Applications (or whatever its called) List of Installed Windows Applications is expanded vertically User Selects Winword from the list Winword loads I'm not really opposed to such a design, I think its more friendly than browsing around in the Applications folders but this all implies having a helper app that we can get in to Winehq. I know I can't write it, I don't know anyone can do it and make Alexandre happy. It is imperative to me to make stock Winehq be functional for the end user and that includes make some way for the user to have easy access to the applications they install under Wine. Given that, I will refocus on sticking the bash script directly in the bundle for now (thanks again for the tip) as I don't think Alexandre will reject that and we can go from there. If someone wants to change it to something else later and can get it in to Winehq, by all means. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
On Sun, Jul 19, 2009 at 7:41 AM, Ken Thomases wrote: > On Jul 17, 2009, at 10:02 PM, Steven Edwards wrote: > >> I tried looking in to generating of AppleScript app >> bundles however there seems to be no documented way to do it other >> than to use the Apple Script tool so no automatted method. > > Are you familiar with the osacompile command? I must have missed that before but I am afraid I don't see what it buys us other than saving hassle building the directory structure by hand. I don't think we want to use AppleScript rather than bash directly as Emmanuel suggested. Take for instance starting a new application, we will need something like do shell script "WINEPREIFX=foo path/to/wine bar.exe" Unless you know of some way to set the environment for only the parent and child applications for a given AppleScript. I found directions on how to do it globally but any shortcuts/scripts/bundles/whatever must honor the WINEPREFIX variable for each application. http://developer.apple.com/qa/qa2001/qa1067.html I am very open to being proved wrong though ;) -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: SVG Logo from the website
On Sat, Jul 18, 2009 at 5:53 PM, Joel Holdsworth wrote: > The icon is the standard "certification" icon taken from the Tango base > set. From what I can see it represents a wax seal - the old way of > certifying one's identity. In fact the original icon has the seal drawn > in yellow on the left of the certificate, so the idea isn't too crazy. > > You could be right though. Maybe the metaphore isn't as clear as it > could be - especially when the UI explicitly uses the word > "certificates". Yes all the other icons seem very intuitive and you guys have been doing great work with this but this one I think might confuse someone. > Drawing high quality icons takes me a long time, so I'm trying to avoid > creating too much work for myself. On the other hand if people think > it's wrong, then I don't mind working to get it right. > > It doesn't matter too much either way though, because cryptui is very > obscure - so obscure that it's only after months of work on this project > that I've been able to find a way to actually display the dialog for the > first time! I had to write custom test software to do it! So whatever > happens the impact on users will be quite low. Hehe sounds like Fun! I don't think we have to replace all of them or at least not at one shot (at least not for something as obscure as this one) because it is a lot of work. I think the old icon is pretty clean in its meaning, it would be nice if we could have something just like it but Tangoised. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: SVG Logo from the website
On Sat, Jul 18, 2009 at 5:12 PM, Joel Holdsworth wrote: > Quick question: Does anyone have an SVG of the wine logo as used on the > wine website? I'd like to use it as part of my graphics refresh to > improve idb_wine.bmp as shown here: > http://www.airwebreathe.org.uk/wine-icon/ I have no idea but I did take a look at your icon work and really like it. I am curious though, the cryptui.dll cert icons don't strike me as right. I can't even tell what they are supposed to be. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
On Fri, Jul 17, 2009 at 10:37 PM, James McKenzie wrote: > Steve: > > Look at the includes, you included several header files twice. > > This is UGLY, but it is a good start. heh yeah thats why its not gone to wine-patch yet, I've just been hacking and slashing, ignore the mess of headers and C++ style comments. Its the design I am still working on. I'm curious if everyone thinks this is the right route to go down. As you can see I've created the helper to invoke generated bash scripts that are stored in the bundle to take care of the environment and the like. I tried looking in to generating of AppleScript app bundles however there seems to be no documented way to do it other than to use the Apple Script tool so no automatted method. At a low level and it embeds its own helper 'applet' program in bundle.app/Contents/MacOS/applet to invoke the embedded AppleScript in bundle.app/Contents/Resources. The carbon C file I included will serve the same purpose for invoking bash and loading our target binary. Later on we will need to teach our bundle helper how to identify Wine windows and cycle through them. Currently all my bundle does is give you the ablity to start a Wine app and have a Dock icon. It's not even a proper parentsuch as if you kill the app in the Dock the Wine child keeps running. As I said it still needs a lot of love but I don't see much other way to do it... Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
On Fri, Jul 17, 2009 at 9:13 PM, James McKenzie wrote: > Bundles are WAY more friendly than using the installer. Installer > programs are meant to remain on the system. +1 Also speaking of bundles I'm going to hijack the thread for a bit, I've got a rough patch going that enables winemenubuilder to be able to spit out bundles when shelllinks are installed. Its still very rough and needs to be redesigned a bit (and Alexandre is not totally sold on parts of the design) but at least its all C. Take a look at the attached patch and give me some feedback if your interested in helping. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo update-bundler.diff Description: Binary data
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
On Thu, Jul 16, 2009 at 11:25 AM, Juan Lang wrote: > Note that I never said it was the user's fault, but that it's a > configuration error. In my opinion the proper place to fix this is in > the library installation itself, or in the distribution of Wine. Mike > Kronenberg's package does that--cheers, Mike--but it's too different > from mainline to be considered stock Wine. A MacOS bundle that > addressed this but was built with no patches at all to git Wine would > be a lot closer to what I want. If this would really be accepted by Winehq then we have that solution. The build script Austin has been developing on my box provides the missing libraries. If we can do releases with it and bundle the missing libraries in our package that will solve a lot of problems. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
On Wed, Jul 15, 2009 at 11:11 AM, Emmanuel Maillard wrote: >> 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? If we want to provide a Winehq support Wine package for OS >> X we have to decide on a configuration that will work and be the least >> invasive to the users when they go to install. >> > > That was the goal of Wine.bundle in Darwine. Austin has updated the dependency build script and we've been using it on my box to build the required libraries but they are not together in a bundle, hence the need for the LD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH changes. What do you think is the best way to resolve this issue? My interest is that I'd like to provide binary packages of Winehq releases however this issue is a real pain. I suppose we could also provide a support package that is separate from the stock Wine package which would supply the missing libraries or whatnot. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch
On Tue, Jul 14, 2009 at 4:17 PM, Juan Lang 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? If we want to provide a Winehq support Wine package for OS X we have to decide on a configuration that will work and be the least invasive to the users when they go to install. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: winequartz.drv Mac OS X UI discontinued?
On Thu, Jul 9, 2009 at 7:18 AM, 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". The link seems to be malformed. Can you resend it? I am really interested in looking at this. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: winequartz.drv Mac OS X UI discontinued?
On Thu, Jul 9, 2009 at 9:02 AM, Adam Strzelecki wrote: > Steven Edwards wrote: > >> While we are on the subject, could anyone point me to a reference that >> would show how I can create a mib file using C? > > You meant Nib? It is binary format which is some Mac equivalent of Windows > RES format. > So this is not a source code. > > Nib can be created from Xib source files (XML files) via "ibtool". Thanks, thats what I need. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: winequartz.drv Mac OS X UI discontinued?
On Thu, Jul 9, 2009 at 4:46 AM, Rolf Kalbermatter wrote: > With the same argument you could say that writing COM objects has > to be done in C++. Yet Wine has lots and lots of COM code written > all in standard C. > > Agreed, writing object oriented code in C is not exactly trivial and > often quite tedious and the difference with Object-C might be even > bigger as it is likely using more advanced techniques. While we are on the subject, could anyone point me to a reference that would show how I can create a mib file using C? Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: why is Kronenberg's Wine/Mac work blacklisted on winehq?
On Fri, Jun 26, 2009 at 4:36 PM, Roderick Colenbrander wrote: > If they ship hacks like the DIB engine then we won't accept bug > reports for it as it a real big hack and shouldn't be linked to from > our website. Tweaking themes or icons is fine. Actually we just need > to refine our .msstyles support and then icon can just be part of a > theme like they are on Windows. Maybe that was a bad example though it is opt-in to turn on the DibEngine even it is installed so the amount of false reports from it should be pretty low. But fine, I grant maybe the DibEngine is slightly invasive and if enabled could lead to bogus bug reports. To my knowledge none of the required patches for a Darwine build with current Wine are very invasive. Normally I wouldn't care about such things but we decided at Wineconf (in Reading I think), when the question of Mac users came up, the consensus was point them at Darwine because nobody wanted to do binary builds. I think we have a brief talk about it at the last Wineconf (I was pretty sick and out of it for most of it) but I don't recall the policy being changed. If we are going to arbitrarily decide to just nuke support for Mike's package (The only semi-actively maintained Darwine) there should be some discussion first because it was a topic at Wineconf. Like I said, I'm happy to offer my box for doing builds if there is really consensus that it needs to change. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: why is Kronenberg's Wine/Mac work blacklisted on winehq?
On Fri, Jun 26, 2009 at 10:51 AM, Dmitry Timoshkov wrote: > 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. I have a Mac that I've given Austin English access to for his Wine hacking needs and he's got a set of scripts for building and running Winetests. I am happy to provide binaries of stock Winehq but I don't see any reason why we can't link to Mike's Darwine build. Maybe he's not had time to cleanup his site, documentation or whatever. As far as the patches go, fewer and fewer of them are needed. Austin has been cleaning up the build script, which btw mostly just satisfies dependencies. I don't know of any major patch we currently need to make stock Wine not suck on OS X. Having the extra Darwine stuff like the helper should not be a problem as it does not mess with Wine directly. For my own tree, the only major hack I've used from Darwine is the wine script that is used to launch Wine. It simply insures the environment is always sane and has the normal stock wine binary renamed to mwine. Certain Linux package maintainers have recently expressed interest in bundling the DIB Engine and custom Icon sets in their Wine packages are we going to stop allowing those package maintainers to link on Winehq if they do this? None of these changes seem like a major enough issue to warrant not supporting the package. I mean hell you support packages built with different compiler revisions, minor glibc, freetype, libxml2, libjpeg, libpng, X11, etc library versions and God only knows how many Linux distribution combinations if someone reports a bug to bugzilla while the mess that is the Linux distro's gets an easy pass. I think its clearly a double standard. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: ActiveX support in IE7
On Thu, Jun 25, 2009 at 6:53 AM, Ben Klein wrote: > This website is plagued by out of date and incorrect information. It > is not endorsed, supported, or recommended by WineHQ (someone correct > me if I'm wrong). Up-to-date information *should* be available on the > AppDB. Heh right I know, God forbid someone link to Winehq and post their own concise useful howto's. We really don't need the traffic and google pagerank for Winehq. I much prefer to only get drunks looking for the latest vintage rather than people interested in running Windows software under Linux. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Alexandre Julliard : configure: Don't accept mingw32 as target name, we need an explicit CPU specification.
On Fri, Jun 19, 2009 at 4:21 PM, Chris Robinson wrote: >> This is not a configure option, it's the name of the installed mingw32 >> binaries. They are supposed to follow the GNU naming convention for >> cross-compilers, and they do on all sane distros AFAIK. > > Gentoo names them with the mingw32- prefix only, on my 32-bit x86 install. Yes Gentoo is the only major odd-man out. We should send a patch upstream for its emerge overlay or whatever they call the think. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Alexandre Julliard : configure: Don't accept mingw32 as target name, we need an explicit CPU specification.
On Fri, Jun 19, 2009 at 1:21 PM, Alexandre Julliard wrote: > This is not a configure option, it's the name of the installed mingw32 > binaries. They are supposed to follow the GNU naming convention for > cross-compilers, and they do on all sane distros AFAIK. Right I get that. I just mean that its pretty common to see homebrewed cross-compilers with just mingw32 as the prefix. The reason I guess is that on Windows (c:\mingw\bin\*) it does not follow the gnu naming convention because it does not have to follow it and people carry that over when they are rolling their own cross-compiler. Now that most distro's are shipping mingw packages this is less common. I guess your argument is right and anyone rolling their own should get with the program and follow the standard. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Alexandre Julliard : configure: Don't accept mingw32 as target name, we need an explicit CPU specification.
On Fri, Jun 19, 2009 at 9:27 AM, Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: ccbf959969e32c9d71d2b4c46dbfe4db1ad2ab3f > URL: > http://source.winehq.org/git/wine.git/?a=commit;h=ccbf959969e32c9d71d2b4c46dbfe4db1ad2ab3f > > Author: Alexandre Julliard > Date: Thu Jun 18 21:35:51 2009 +0200 > > configure: Don't accept mingw32 as target name, we need an explicit CPU > specification. I don't think this change is right. It is a very common convention to use mingw32 as a generic convention for 32bit x86. It seems the best practice would be if mingw32 is passed then to assume a sensible lowest common default. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: PATCH - enhance the help message in expand
On Fri, Jun 12, 2009 at 10:56 AM, Detlef Riekenberg wrote: > Mixing the case looks strange. > (Files/files, Destination/destination) > > Please move the helpmsg to a resource, to make translations possible. I already told Alexandre to ignore my spam on the account of it does not properly stub the unimplemented functions anyway and I agree it should use the resources. I was hoping when I looked at it that adding the case for multiple cabinet files would be less of a hassle... -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: OS X build broken
On Fri, Jun 12, 2009 at 4:12 AM, Alexandre Julliard wrote:
> Austin English writes:
>
>> AJ, looks like your 'configure: Detect the appropriate form for the
>> __ASM_GLOBAL_FUNC macro.' patch broke the compile on OS X. Could you
>> have a look?
>
> It works fine here. What does your __ASM_GLOBAL_FUNC macro look like in
> include/config.h?
This is what I have,
/* Define to a macro to generate an assembly function */
#define __ASM_GLOBAL_FUNC(name,code) asm(".text\n\t.align 4\n\t.globl _" #name "
\n\t\n_" #name ":\n\t" code "");
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Re: OS X build broken
On Thu, Jun 11, 2009 at 11:39 PM, Austin English wrote: > AJ, looks like your 'configure: Detect the appropriate form for the > __ASM_GLOBAL_FUNC macro.' patch broke the compile on OS X. Could you > have a look? Bah you beat me reporting this by 13mins! :P -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Alexandre Julliard : configure: Detect the appropriate form for the __ASM_GLOBAL_FUNC macro.
Hi, On Thu, Jun 11, 2009 at 11:54 AM, Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 857f1e0924f23865038a608ee6834ef524371f20 > URL: > http://source.winehq.org/git/wine.git/?a=commit;h=857f1e0924f23865038a608ee6834ef524371f20 > > Author: Alexandre Julliard > Date: Thu Jun 11 16:32:42 2009 +0200 > > configure: Detect the appropriate form for the __ASM_GLOBAL_FUNC macro. I believe this patch is causing a problem for me on OS X Leopard gcc version 4.0.1 (Apple Inc. build 5465). When I try to compile riched20 with a clean tree at HEAD I am getting this ld: absolute addressing (perhaps -mdynamic-no-pic) used in _itextHostStdcallVtbl from txthost.o not allowed in slidable image collect2: ld returned 1 exit status winegcc: gcc failed make: *** [riched20.dll.so] Error 2 Is the __ASM_GLOBAL_FUNC stdcall wrapper in txthost.c just borked? Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: How do I actually write a testcase for a 16-bit API ?
On Mon, Jun 8, 2009 at 4:09 PM, Alex Villacís Lasso wrote: > I downloaded the tests from win16test.googlecode.com , but the tarball > already has a small backlog of patches that have not yet been integrated > into Wine (checked with patch --dry-run). Why? I could make a patch to the > testsuite from win16test.googlecode.com, but will this help at all on > getting the fix integrated into Wine? We need someone to do the configure magic of detecting OpenWatcom if installed and teach configure and friends how to build. The win16 test suite has kind of been in bitrot mode as no one has taken the time to integrate it. Of course you might want to double check with Alexandre as to his preference. He might prefer at this point to just keep the win16 tests out of the tree. I don't know. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Alexandre Julliard : winegcc: Create a stub main to work around the lack of Unicode support in Mingw.
On Fri, Jun 5, 2009 at 9:56 AM, Alexandre Julliard wrote: > winegcc: Create a stub main to work around the lack of Unicode support in > Mingw. Thank you. The mingw developers policy opposing adding this entry point baffles me. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Socks support in ws2_32
On Fri, Jun 5, 2009 at 9:40 AM, Gabriele Greco wrote: > Hello guys, I'm lurking this list since a pair of weeks but I've not yet > posted here. > I've added socks 4/5 support right inside of ws2_32 library, I've tested it > with various applications and it works correctly both with sync and async > sockets (only TCP). The code works very well also with fairly intensive > network apps like "world of warcraft" :) > At the moment the support is activated by enviroment variables > (SOCKS_SERVER/SOCKS_PROTOCOL/SOCKS_USER/...) and the code is not very clean. > I've seen that wine patches are not accepted if not cleaned up, so I wanted > to ask if my effort can be of any interest for the official GIT or if I'll > have to mantain it for myself on my local GIT (I've written this patch > mostly for personal use since I need socks support to use certain services > cut down by the company firewall). > Obviously if there is any interest to see socks support inside wine I'll try > to clean up the patch and make it follow the specs that the > wine socks support is supposed to have (for instance configurability through winecfg for example). It sounds very useful. If there is not already a bug regarding socks, then I suggest filing one and posting the patch there as interested parties can comment and help point out bugs, design changes needed, etc. You can also send your patch here for review. Right off the bat I'd say the variables need to go. Alexandre is very picky about adding new variables to Wine. I assume there are some registry keys where a socks proxy is stored, it may even be the same place where normal proxy information is stored and an extra key to define if it uses socks or not. I would try looking at something like IE and see how it sets the proxy server stuff. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Extending winemenubuilder to create Application Bundles on OS X
Hi, Recently I've been doing a lot of hacking on my local tree for OS X projects. The lack of support in winemenubuilder to generate application bundles for installed applications from ShellLinks like we do for FreeDesktop items has been killing me. I've just been building simple wrapper scripts which is fine but very ugly. I've recently spoken with Sveinbjorn Thordarson who wrote the Platypus App Bundler (which is a very kick-ass utility) and he has allowed me to use his code under LGPL to extend winemenubuilder. Some nice things about Platypus is that while its written in Objective C, its very modular and already has an optional cli interface. I'm pretty sure I can isolate out all of the stuff we don't need in short order and extend winemenubuilder a bit with its code as a reference. I'm going to file a detailed bug report describing how we need to extend winemenubuilder, what application bundles are, and what else we will need. If anyone is interested in jumping in and helping, we still need to do conversion from *.ico to a *.icns icons which requires a bit of hacking. Currently I'm doing something like the following 1. hacked winemenubuilder converts and export the icon (*.ico file) to png 2. convert from png to tiff sips -s format tiff [png file] --out [(converted file).tiff] 3. Convert tiff to icns tiff2icns -noLarge [tiff file] [icns file] I kind of doubt Alexandre will want a patch doing all of this conversion for simple icons and I'm sure someone has to have documented icns somewhere. The iPhone App bundles seem to support *.png icons but from my reading it does not seem that standard OS X applications do. Maybe this will change in Snow Leopard, I've tried to hack my test bundles and make them use normal png images without much luck. If your interested in helping, researching this and if needed, adding exporting the icon resources straight to icns would be a good place to start. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo -- Forwarded message -- From: Sveinbjorn Thordarson Date: Sat, May 30, 2009 at 9:13 AM Subject: Re: Web Email Form: Developing a Platypus-lite for Wine To: winehac...@gmail.com Hello there, I would be happy to relicense parts of the Platypus code under the LGPL. Please feel free to use it as you like under those terms. All the best, Sveinbjorn Thordarson On 30 May 2009, at 04:22, winehac...@gmail.com wrote: > Hi, > I am writing because I am wondering if you would be willing to relicense some > code I might need under the LGPL. > > I am interested in adding support to Wine's menubuilding application which > creates FreeDesktop menus and desktop launchers under Linux for Windows based > applications. Currently it parses either a *.lnk or a given executable to > generate a *.desktop file for use under Gnome or KDE. When running Wine under > OS X, it for the most part sucks because we cannot generate menus of any > type. I'd like to take platypus, rip out everything I don't need and just use > parts of it in winemenubuilder. > > The only problem is Wine is LGPL and your project is GPL. Since I know > NOTHING of Obj-C and am new to OS X development in general your tool would > save me a lot of time as a frame of reference but I do not wish to violate > your copyright in any way. > > Would it be acceptable for me to use parts of your code under the LGPL in > this fashion? > > Thanks > Steven >
Re: Alexandre Julliard : rpcrt4: Change the allocation of delegated stub methods so that we never need to free them .
On Tue, Jun 2, 2009 at 9:44 AM, Alexandre Julliard wrote: > +#define MAX_BLOCKS 64 /* 64k methods should be enough for anybody */ lol, best. comment. ever! -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
