Re: Patchsets that need review by experienced Wine Developers
André Hentschel n...@dawncrow.de writes: We should decide soon if we want to accept that patch, because it breaks DOSBox compatiblity. So in case we commit it we should change it in dosbox before they release 0.75 AJ? No, that would also break compatibility with existing prefixes. -- Alexandre Julliard julli...@winehq.org
Re: Patchsets that need review by experienced Wine Developers
On Thu, Jan 03, 2013 at 05:22:14PM -0500, jordan wrote: Hi, I have been experimenting with some patchsets for Wine - based on an implementation of Wine originally developed By Muse Research. It has improved support for a bunch of stuff, fixes (most) bottlenecks for Linux proaudio folks making use of Wine + Jack, and also contains some bug fixes for wine (that may or may not be acceptable to wine-devs.) I have a project that now lives on SF.net, but has been running for months now, on my machine(s), locally. It's called L-ProAudio, and the version of wine (L_pa-Wine) is geared towards proaudio users. We also have support in 1 linux application ~ which now properly handles the new method of mapping win/prio - linux/prio. Some of the patchset fixes synchronization issues (with jack), disk geomtery-io-syscl, fixes rendering bugs in VSTs (probably other apps too) and a bunch of other improvements (geared for proaudio users). L_ProAudio SF.net Page: https://sourceforge.net/projects/l-proaudio/ - Wine-L_Proaudio_Arch_n_patches.tar.gz contains a pkgbuild for Archlinux (like gentoo' ebuild) + all patches (and probably one or two others, not used in my builds). But please note: this is NOT a fork of Wine. It is necessary for me to be able to run the applications that i want with Wine. I am just carrying patchwork and re-basing it, as time passes. But i decided to release it - since it benefits the larger community who uses this stuff (greatly). note 2: I am posting, in order to shed light on any improvements/bug fixes that _might_ be suitable for upstream. ~ If so, once a given stable release of Wine is issued, I would then be able to remove them from my patchset, minimizing duplicate efforts, among other things. The original patches/sources (that i have based my version on, are found here: http://www.museresearch.com/support/receptor-faq.php ...at the bottom of the page / last link: http://www.museresearch.com/support/receptor-faq.php these patches fix Wine problems (in most areas) for people using linux(-rt) + jack + ProAudio ... but may have other benefits/bug-fixes for wine. It's Gpl'd (obviously), so it would be worthwhile to have a look anyway. - didn't include every patch (some of them aren't of interest to me, outdated, etc). I looked over them briefly. 0005-Expand-dos-has-entropy-in-order-to-make-collision-le.patch Not sure why this is needed? 0010-If-a-child-of-the-window-being-disabled-is-the-captu.patch a user32.EnableWindow 2008 patch ... is it still needed for you, as quite some enhancements have happened... Would need review (likely from julliard or other user32 guru) and testcases. 0012-ntdll-Use-pipes-for-synchronization-objects.patch 0050-pipe-check-and-thread-safe-read.patch A new synchronization method using UNIX pipe(2)s. This is definitely not going in as is... It would be interesting to know what deficit in regular Wine is fixed by it. wineserver overhead? 0023-improve-IoRegisterDeviceInterface.patch Remove the MUSE specific fixmes and use the same FIXME() style for stub parameters as in the other FIXME()s. Then its ready for wine-patches I would say. 0025-Add-stub-for-IoSetDeviceInterfaceState.patch Use same FIXME() style as used for other stub functions, then ready for submission. 0027-Add-stub-for-PoSetPowerState.patch Good for submission as-is. 0033-overridable-default-filesystem-type.patch Not submittable as-is ... It would be good to know the reason and/or what MUSE expects. 0044-get-windows-label-from-registry.patch Smells like the wrong place to do it. Perhaps mountmgr.sys, but perhaps different. Also unclear if Alexandre likes it. 0052-NI-drag-and-drop.patch Looks already good for submission to me. 0054-set-realtime-priority-without-wineserver.patch wine-rt-101107.patch Needs design and discussion... So far a RT solution was not accepted for Wine yet. 0061-fix-broken-cross-compiled-winegcc.patch 0063-disable-winedbg-auto-crash-dialog.patch local hacks 0062-disable-crashing-alpha-bitmaps-for-gdb.patch Seems like a mistaken patch that was needed as we had the old DIB sections. gdb would have accepted continue here. Should not be necessary anymore these days with the DIBENGINE. add-implementation-setProcessWorkingSetSize.patch Might be submittable as-is. Might need autoconf checks for non-Linux. Fix-disk-geometry-ioctl.patch Alexandre usually does not like override files like this unless necessary. What is actually expected? you mentioned rendering issues? fix-obscured-windows.patch Hmm, needs user32 windowing guru review. menu-border-color.patch If this is not just a hack, could be submitted as-is.
Re: Patchsets that need review by experienced Wine Developers
The original patches/sources (that i have based my version on, are found here: http://www.museresearch.com/support/receptor-faq.php ...at the bottom of the page / last link: http://www.museresearch.com/support/receptor-faq.php these patches fix Wine problems (in most areas) for people using linux(-rt) + jack + ProAudio ... but may have other benefits/bug-fixes for wine. It's Gpl'd (obviously), so it would be worthwhile to have a look anyway. - didn't include every patch (some of them aren't of interest to me, outdated, etc). I looked over them briefly. 0005-Expand-dos-has-entropy-in-order-to-make-collision-le.patch Not sure why this is needed? I'm not sure why either, but i am guessing it improves things in a linux-rt/VST setting (in fact, removing it causes regressions on my L_pa systems - so i am keeping it. 0010-If-a-child-of-the-window-being-disabled-is-the-captu.patch a user32.EnableWindow 2008 patch ... is it still needed for you, as quite some enhancements have happened... Would need review (likely from julliard or other user32 guru) and testcases. Seems to be, yeah. 0012-ntdll-Use-pipes-for-synchronization-objects.patch 0050-pipe-check-and-thread-safe-read.patch A new synchronization method using UNIX pipe(2)s. This is definitely not going in as is... Figured as much :) (that was pretty obvious lol.) It would be interesting to know what deficit in regular Wine is fixed by it. wineserver overhead? Yeah, Wineserver is probably the number one thing that slows down when, when you are looking for low-latency / high-performance. (ext4 is also terrible on stock settings). 0023-improve-IoRegisterDeviceInterface.patch Remove the MUSE specific fixmes and use the same FIXME() style for stub parameters as in the other FIXME()s. Then its ready for wine-patches I would say. Awesome :) I must have missed that ~ you will notice that i removed them from the new variables used by L_ (didn't want any hassles/trademark issues with Muse). 0025-Add-stub-for-IoSetDeviceInterfaceState.patch Use same FIXME() style as used for other stub functions, then ready for submission. Great. 0027-Add-stub-for-PoSetPowerState.patch Good for submission as-is. Great. :) 0033-overridable-default-filesystem-type.patch Not submittable as-is ... It would be good to know the reason and/or what MUSE expects. You can contact them. They don't seem to get the idea of FOSS - by having our help, they could have _Less_ of a delta they are keeping. But as far as this patch is concerned, i am not sure. (this is why i got in touch with you guys). 0044-get-windows-label-from-registry.patch Smells like the wrong place to do it. Perhaps mountmgr.sys, but perhaps different. Also unclear if Alexandre likes it. I think for their purposes it probably is though, so i have kept it as well (for now, unless told that i shouldn't for good reason). 0052-NI-drag-and-drop.patch Looks already good for submission to me. Yeah, it fixes BIG hassles for N.I users like myself. 0054-set-realtime-priority-without-wineserver.patch wine-rt-101107.patch Needs design and discussion... So far a RT solution was not accepted for Wine yet. Yeah - that is in fact, one of the most important patches for us (linuxaudio folks). The FSThost developer (wraps wineVSTs, single hosted) said it is the 'holy grail' for fixing his software to properly handle windows VSTs and it does so very well :) ~ windows VSTs are highly performant, synchronized and run like normal Jack_cleints without wineserver getting in the way. 0061-fix-broken-cross-compiled-winegcc.patch 0063-disable-winedbg-auto-crash-dialog.patch local hacks k. 0062-disable-crashing-alpha-bitmaps-for-gdb.patch Seems like a mistaken patch that was needed as we had the old DIB sections. gdb would have accepted continue here. Should not be necessary anymore these days with the DIBENGINE. Okay, i will try reverting it locally and make sure everything is good. add-implementation-setProcessWorkingSetSize.patch Might be submittable as-is. Might need autoconf checks for non-Linux. good. but i am not the guy to do this ~ i have a _ton_ of work right now, both professionally and for my own projects. I just wanted to make sure anything that _should_ be in wine goes into Wine to improve the experience for everyone. Fix-disk-geometry-ioctl.patch Alexandre usually does not like override files like this unless necessary. What is actually expected? you mentioned rendering issues? I am not sure about this one. it needs investigating but i have it applied. As far as rendering issues, yes upstream wine causes ugly flickering in some apps/VSTs, while L_pa-Wine does not (at all,
Re: Patchsets that need review by experienced Wine Developers
Also, as a general note Marcus (and any other wine-developer who may be reading this). If you guys ever happen to come accross patches that may fix issues for me, but aren't suitable for upstream ~ please contact me and pass them along. since i am targeting a much smaller audience with 'particular' needs, i would like to improve the experience, as best as i can for those purposes. Thanks again. Jordan
Re: Patchsets that need review by experienced Wine Developers
Hi, list. We at Muse Research are happy help move our patches from custom one-offs to the main fork. Background info below... The original patches/sources (that i have based my version on, are found here: http://www.museresearch.com/support/receptor-faq.php ...at the bottom of the page / last link: http://www.museresearch.com/support/receptor-faq.php I looked over them briefly. 0005-Expand-dos-has-entropy-in-order-to-make-collision-le.patch Not sure why this is needed? I'm not sure why either, but i am guessing it improves things in a linux-rt/VST setting (in fact, removing it causes regressions on my L_pa systems - so i am keeping it. This is a really old patch. IIRC there were different long filenames that were being converted to the same 8.3 filename. I don't have more details. 0010-If-a-child-of-the-window-being-disabled-is-the-captu.patch a user32.EnableWindow 2008 patch ... is it still needed for you, as quite some enhancements have happened... Would need review (likely from julliard or other user32 guru) and testcases. Seems to be, yeah. This fixed a problem where FM8's 'save' window would get stuck. Once you opened and cancelled it, any mouse click would open it again. 0012-ntdll-Use-pipes-for-synchronization-objects.patch 0050-pipe-check-and-thread-safe-read.patch A new synchronization method using UNIX pipe(2)s. This is definitely not going in as is... Figured as much :) (that was pretty obvious lol.) It would be interesting to know what deficit in regular Wine is fixed by it. wineserver overhead? Yeah, Wineserver is probably the number one thing that slows down when, when you are looking for low-latency / high-performance. (ext4 is also terrible on stock settings). This removes key synchronization calls from the wineserver and keeps them on the app side. Without it realtime performance is impossible. We developed this with Codeweavers, and they were pretty sure it wasn't general enough for the main fork. 0023-improve-IoRegisterDeviceInterface.patch Remove the MUSE specific fixmes and use the same FIXME() style for stub parameters as in the other FIXME()s. Then its ready for wine-patches I would say. Awesome :) I must have missed that ~ you will notice that i removed them from the new variables used by L_ (didn't want any hassles/trademark issues with Muse). Don't worry, no problem with us! This was helpful in getting Pace CDRM ilok support to work. 0025-Add-stub-for-IoSetDeviceInterfaceState.patch Use same FIXME() style as used for other stub functions, then ready for submission. Great. 0027-Add-stub-for-PoSetPowerState.patch Good for submission as-is. Great. :) Ditto from 0023. 0033-overridable-default-filesystem-type.patch Not submittable as-is ... It would be good to know the reason and/or what MUSE expects. You can contact them. They don't seem to get the idea of FOSS - by having our help, they could have _Less_ of a delta they are keeping. But as far as this patch is concerned, i am not sure. (this is why i got in touch with you guys). This is internal and not generally useful. 0044-get-windows-label-from-registry.patch Smells like the wrong place to do it. Perhaps mountmgr.sys, but perhaps different. Also unclear if Alexandre likes it. I think for their purposes it probably is though, so i have kept it as well (for now, unless told that i shouldn't for good reason). This one is internal too. 0052-NI-drag-and-drop.patch Looks already good for submission to me. Yeah, it fixes BIG hassles for N.I users like myself. Cool. 0054-set-realtime-priority-without-wineserver.patch wine-rt-101107.patch Needs design and discussion... So far a RT solution was not accepted for Wine yet. Yeah - that is in fact, one of the most important patches for us (linuxaudio folks). The FSThost developer (wraps wineVSTs, single hosted) said it is the 'holy grail' for fixing his software to properly handle windows VSTs and it does so very well :) ~ windows VSTs are highly performant, synchronized and run like normal Jack_cleints without wineserver getting in the way. Same as above, moving sync calls out of the wineserver is the only way to use Wine for realtime audio applications. Especially with more complicated plugins like Kontakt. 0061-fix-broken-cross-compiled-winegcc.patch This fixed a compiler problem when cross compiling a 32bit winelib application on a 64bit system. The messages were: /usr/include/wine/windows/rpcndr.h:176:16: error: ‘_MIDL_STUB_MESSAGE’ has a field ‘_MIDL_STUB_MESSAGE::SavedContextHandles’ whose type uses the anonymous namespace [-Werror] /usr/include/wine/windows/rpcndr.h:479:16: error: ‘_SCONTEXT_QUEUE’ has a field ‘_SCONTEXT_QUEUE::ArrayOfObjects’ whose type uses the anonymous namespace
Re: Patchsets that need review by experienced Wine Developers
We at Muse Research are happy help move our patches from custom one-offs to the main fork. Background info below... -- Michael Ost Muse Research and Development Hi Michael, I recognize your name from years ago on various (linux-related) lists. I hope you don't mind that i took the initiative here. :) This benefits us all ~ less of a delta for you, less for me and improved Wine support for everybody ~ it's a win win situation. In reality, the strength of your product line is not secret sauce to wine, when you really think about it... the benefit is the amazing software + H/W that you guys have designed. ~ i've used them, but can't _justify_ the expense, at this point ~ although i would love a Receptor :) (and _would_ own one if i was a touring professional, since it is simply the best option available) Anyway, Michael - i hope you didn't take any of this as 'stepping on your toes'. I also hope it isn't a problem that within my project; L_ProAudio that i have _renamed_ all of the MUSE stuff ~ being as that is your trademark. also, if you are interested later down the line (once, the project is slightly more mature), we could share some tips on taming linux-rt, but that is entirely upto you guys. lastly, thank you very much for publishing your GPL'd code. It fixes a lot of hassles for me. cheerz Jordan
Re: Patchsets that need review by experienced Wine Developers
Hi! I'm really happy that some of our patches are making it into WINE! If I could chime in... 0005-Expand-dos-has-entropy-in-order-to-make-collision-le.patch Not sure why this is needed? I'm not sure why either, but i am guessing it improves things in a linux-rt/VST setting (in fact, removing it causes regressions on my L_pa systems - so i am keeping it. This is a really old patch. IIRC there were different long filenames that were being converted to the same 8.3 filename. I don't have more details. That was because of a name collision that'd happen when running the installer for NI's Akoustik Piano plugin. It creates hundreds (or thousands?) of files with similar names in one directory, and the installer would name the file one thing but in the file would be another file's contents. IIRC, it was a pretty unusual case. 0012-ntdll-Use-pipes-for-synchronization-objects.patch 0050-pipe-check-and-thread-safe-read.patch A new synchronization method using UNIX pipe(2)s. This is definitely not going in as is... Figured as much :) (that was pretty obvious lol.) It would be interesting to know what deficit in regular Wine is fixed by it. wineserver overhead? Yeah, Wineserver is probably the number one thing that slows down when, when you are looking for low-latency / high-performance. (ext4 is also terrible on stock settings). This removes key synchronization calls from the wineserver and keeps them on the app side. Without it realtime performance is impossible. We developed this with Codeweavers, and they were pretty sure it wasn't general enough for the main fork. This might also end up being generally useful for programs that are realtime and make a lot of wineserver calls. I believe the mutexes were taking too long to access because they were going through wineserver, which was already handling a lot of other calls in serial. Basically, it was a traffic jam. That's my understanding and recollection, at least (I wasn't the original author of the patch but I did do some work on it later). Louis Gorenfeld Muse Research
Re: Patchsets that need review by experienced Wine Developers
On 04.01.2013 22:33, Louis Gorenfeld wrote: Hi! I'm really happy that some of our patches are making it into WINE! If I could chime in... 0005-Expand-dos-has-entropy-in-order-to-make-collision-le.patch Not sure why this is needed? I'm not sure why either, but i am guessing it improves things in a linux-rt/VST setting (in fact, removing it causes regressions on my L_pa systems - so i am keeping it. This is a really old patch. IIRC there were different long filenames that were being converted to the same 8.3 filename. I don't have more details. That was because of a name collision that'd happen when running the installer for NI's Akoustik Piano plugin. It creates hundreds (or thousands?) of files with similar names in one directory, and the installer would name the file one thing but in the file would be another file's contents. IIRC, it was a pretty unusual case. We should decide soon if we want to accept that patch, because it breaks DOSBox compatiblity. So in case we commit it we should change it in dosbox before they release 0.75 AJ?
Re: Patchsets that need review by experienced Wine Developers
This might also end up being generally useful for programs that are realtime and make a lot of wineserver calls. I believe the mutexes were taking too long to access because they were going through wineserver, which was already handling a lot of other calls in serial. Basically, it was a traffic jam. That's my understanding and recollection, at least (I wasn't the original author of the patch but I did do some work on it later). +1 That matches my experiences, as well, Louis. ext4 likes to jam up things to, so ideally if these problems are going to be solved upstream ~ wine-devs also will likely want to look at problems with ext4 (possibly, btrfs down the line ~ since i think i remember noticing a kernel hack for btrfs(?). anyway, that is another issue all together. Jordan
Patchsets that need review by experienced Wine Developers
Hi, I have been experimenting with some patchsets for Wine - based on an implementation of Wine originally developed By Muse Research. It has improved support for a bunch of stuff, fixes (most) bottlenecks for Linux proaudio folks making use of Wine + Jack, and also contains some bug fixes for wine (that may or may not be acceptable to wine-devs.) I have a project that now lives on SF.net, but has been running for months now, on my machine(s), locally. It's called L-ProAudio, and the version of wine (L_pa-Wine) is geared towards proaudio users. We also have support in 1 linux application ~ which now properly handles the new method of mapping win/prio - linux/prio. Some of the patchset fixes synchronization issues (with jack), disk geomtery-io-syscl, fixes rendering bugs in VSTs (probably other apps too) and a bunch of other improvements (geared for proaudio users). L_ProAudio SF.net Page: https://sourceforge.net/projects/l-proaudio/ - Wine-L_Proaudio_Arch_n_patches.tar.gz contains a pkgbuild for Archlinux (like gentoo' ebuild) + all patches (and probably one or two others, not used in my builds). But please note: this is NOT a fork of Wine. It is necessary for me to be able to run the applications that i want with Wine. I am just carrying patchwork and re-basing it, as time passes. But i decided to release it - since it benefits the larger community who uses this stuff (greatly). note 2: I am posting, in order to shed light on any improvements/bug fixes that _might_ be suitable for upstream. ~ If so, once a given stable release of Wine is issued, I would then be able to remove them from my patchset, minimizing duplicate efforts, among other things. The original patches/sources (that i have based my version on, are found here: http://www.museresearch.com/support/receptor-faq.php ...at the bottom of the page / last link: http://www.museresearch.com/support/receptor-faq.php these patches fix Wine problems (in most areas) for people using linux(-rt) + jack + ProAudio ... but may have other benefits/bug-fixes for wine. It's Gpl'd (obviously), so it would be worthwhile to have a look anyway. - didn't include every patch (some of them aren't of interest to me, outdated, etc). Take care Jordan
Free VMware Workstation licenses for Wine developers
I already announced this at WineConf, but for people who were not there: VMware wants to support the Wine project by providing free of charge Workstation 7 licenses to Wine developers. We're not going to be too picky about the definition of Wine developer. If you have been able to get a patch past Alexandre you've shown enough dedication to qualify ;-). There are a few restrictions on these licenses: - Not for resale - Not upgradable - No support entitlement If you want a license, just send me an email (off-list). Ge.
Re: Sending updates to wine developers guide
On Sat, 23 Feb 2008, Austin English wrote: I was looking at the website.git online, I can't find the documentation so I can edit it. http://source.winehq.org/git/website.git/?a=blob;f=templates/en/documentation.template references /docs/, but that doesn't exist on git. I'm sure a lot of the info is outdated, but I was mostly looking to fix the regression testing guides, which still reference CVS, and are horribly outdated. Any possibility of adding /docs/ to website.git? The Wine documentation is in a separate repository: http://www.winehq.org/site/git#docs The documentation lives in a separate CVS tree on Sourceforge. To get a git repository of the documentation create a new directory and in a terminal run in that directory: git cvsimport -v -k -d :pserver:[EMAIL PROTECTED]:/cvsroot/wine docs -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *^%$#@ thing ever since. Moral: design before you implement.
Sending updates to wine developers guide
I was looking at the website.git online, I can't find the documentation so I can edit it. http://source.winehq.org/git/website.git/?a=blob;f=templates/en/documentation.template references /docs/, but that doesn't exist on git. I'm sure a lot of the info is outdated, but I was mostly looking to fix the regression testing guides, which still reference CVS, and are horribly outdated. Any possibility of adding /docs/ to website.git? -Austin
re: Sending updates to wine developers guide
I can't find the documentation so I can edit it. Look at the bottom of http://winehq.org/site/git The command to load it into a local git repository is git cvsimport -v -k -d :pserver:[EMAIL PROTECTED]:/cvsroot/wine docs You can then send in patches.
Details: Wine Developers Wanted for Commercial Open Source project - Wine on Cygwin and Windows
I got a lot of people asking me to post details about our intended project. Basically, what we are trying to do is run native Windows applications on a remote X desktop; we feel that the best way to do this would be to use wine as a base to develop a Windows to X translator/mapping, and then export the X calls over the network. It looks like wine should already implement much of the needed functionality in order to run Windows applications on Linux, so a windows port of the display code tied into an Xserver seems to make the most sense as a way forward. We're looking at contracting a development team to work on this with an estimated time to completion of 3 months, and are comfortable with an open source development model. The finished product will of course be released under the GPL. Feedback on this idea is welcome. Interested developers/organizations can contact me at [EMAIL PROTECTED] Chetan
Re: Experienced Wine Developers Wanted for Commercial Open Source project - Wine on Cygwin and Windows
I got a lot of people asking me to post details about our intended project. Basically, what we are trying to do is run native Windows applications on a remote X desktop; we feel that the best way to do this would be to use wine as a base to develop a Windows to X translator/mapping, and then export the X calls over the network. It looks like wine should already implement much of the needed functionality in order to run Windows applications on Linux, so a windows port of the display code tied into an Xserver seems to make the most sense as a way forward. We're looking at contracting a development team to work on this with an estimated time to completion of 3 months, and are comfortable with an open source development model. The finished product will of course be released under the GPL. Feedback on this idea is welcome. Interested developers/organizations can contact me at [EMAIL PROTECTED] Chetan -- Chetan Venkatesh [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] My company is looking for experienced Wine Developers to work on a commercial Open Source Project involving getting wine working under cygwin and Windows. Can anyone point me to the right mailing list / forum to make a posting at or can interested developers contact me please - [EMAIL PROTECTED] Regards Chetan
Re: Experienced Wine Developers Wanted for Commercial Open Source project - Wine on Cygwin and Windows
Am Mittwoch 10 Januar 2007 16:53 schrieb Chetan Venkatesh: Basically, what we are trying to do is run native Windows applications on a remote X desktop; we feel that the best way to do this would be to use wine as a base to develop a Windows to X translator/mapping, and then export the X calls over the network. It looks like wine should already implement much of the needed functionality in order to run Windows applications on Linux, so a windows port of the display code tied into an Xserver seems to make the most sense as a way forward. This sounds interesting, but I am not sure how much you can gain with that compared to running wine on Linux. I think those are the DLLs of which you will have to run the Wine version and the Windows version won't work: gdi, user, winex11.drv, opengl32, ddraw, d3d8, d3d9, kernel. Shell32 and advapi are not really related to the X server, but the use of wine's kernel32.dll may require them. Of course you won't need opengl or d3dX if you don't plan to use 3d graphics. On top of those libs you can use native windows libraries of course. But you can do that equally well on Linux, MacOS or Windows. The advantage of windows will be of course that the libraries are already available and you don't get license issues(well, IANAL). And of course it would be very tempting to port Wine completely to Windows. Higher level DLLs can be compiled for and used on windows already, but they are pretty pointless(appart from debugging). These are mostly the same dlls where the windows version can be used on wine. And we plan to port our Direct3D to Windows to get d3d10 on windows xp(once wine has d3d10) pgpkEgbzFavf5.pgp Description: PGP signature
Experienced Wine Developers Wanted for Commercial Open Source project - Wine on Cygwin and Windows
My company is looking for experienced Wine Developers to work on a commercial Open Source Project involving getting wine working under cygwin and Windows. Can anyone point me to the right mailing list / forum to make a posting at or can interested developers contact me please - [EMAIL PROTECTED] Regards Chetan
Re: Experienced Wine Developers Wanted for Commercial Open Source project - Wine on Cygwin and Windows
Hello Chetan, I believe this link will be of help : http://www.codeweavers.com/services/ Regards, Tom On 1/9/07, Chetan Venkatesh [EMAIL PROTECTED] wrote: My company is looking for experienced Wine Developers to work on a commercial Open Source Project involving getting wine working under cygwin and Windows. Can anyone point me to the right mailing list / forum to make a posting at or can interested developers contact me please - [EMAIL PROTECTED] Regards Chetan
Re: Experienced Wine Developers Wanted for Commercial Open Source project - Wine on Cygwin and Windows
Am Dienstag 09 Januar 2007 19:41 schrieb Chetan Venkatesh: My company is looking for experienced Wine Developers to work on a commercial Open Source Project involving getting wine working under cygwin and Windows. Can anyone point me to the right mailing list / forum to make a posting at or can interested developers contact me please - [EMAIL PROTECTED] I think this list is a good place for such things too. At least people will comment on the technical aspects :-) And I think everyone here(including me) will be interested in details of what you want to do :-) pgpvkjsdb4ANY.pgp Description: PGP signature
Re: Wine developers?
On Mon, 26 Jun 2006 08:27:10 +1000, Troy Rollo wrote: On Friday 23 June 2006 22:50, Mike Hearn wrote: A very specific legal interpretation that would require the company behind Thinstall to want to hurt the Wine project be careful, none of us are lawyers here. That's not entirely true. We have IP lawyers on wine-devel? Can you say who? thanks -mike
Re: Wine developers?
On Wednesday 28 June 2006 02:11, Mike Hearn wrote: On Mon, 26 Jun 2006 08:27:10 +1000, Troy Rollo wrote: On Friday 23 June 2006 22:50, Mike Hearn wrote: careful, none of us are lawyers here. That's not entirely true. We have IP lawyers on wine-devel? Can you say who? I'm a non-practising lawyer, and my training does include IP law. There may be one or two others lurking - as I recall there were some others on the wine-legal list before it was shut down. -- Troy Rollo - [EMAIL PROTECTED]
Re: Wine developers?
On Friday 23 June 2006 22:50, Mike Hearn wrote: A very specific legal interpretation that would require the company behind Thinstall to want to hurt the Wine project be careful, none of us are lawyers here. That's not entirely true. -- Troy Rollo - [EMAIL PROTECTED]
Re: Wine developers?
On Tue, 20 Jun 2006 19:32:11 -0600, Vitaliy Margolen wrote: Basically you are _stealing_ developers from the project. Because with your closed source project such developer will be prohibited from participating in the Wine project. A very specific legal interpretation that would require the company behind Thinstall to want to hurt the Wine project be careful, none of us are lawyers here.
Re: Wine developers?
Hiya Jonathon, I wouldn't worry too much about the negative reactions there, which is a shame. As Molle has pointed out he is not really a Wine developer. I am and I'd say that it's totally fine to post such a job advert here, I'm sure there are people here who would like to find a good job with their skills. I hope you fill the position soon! Good luck! thanks -mike On Tue, 20 Jun 2006 13:59:59 -0700, Jonathan Clark wrote: My name is Jonathan Clark, and I work with a team on a project that has some similarities with Wine. The project is called Thinstall (http://thinstall.com), and on first glance similarities may not be apparent.
Re: Wine developers?
On Wednesday 21 June 2006 21:24, Vitaliy Margolen wrote: Wednesday, June 21, 2006, 11:41:32 AM, Andreas Mohr wrote: Hi, On Wed, Jun 21, 2006 at 07:27:28PM +0200, Kai Blin wrote: I wouldn't necessarily judge the whole list by just two negative reactions. It's interesting to see that with my wine experience there might be jobs out there working on something similar. (Not that I'm interested right now, I'm still at university...) I'm sure you're aware that in every open source project, there's people who oppose commercial software development for philosophical reasons. proprietary please, not commercial. HUGE difference. I was talking more about nature of the job. I'm sure that lots of Wine code can leak into commercial product and wise versa. What's worse is that it already DID happen, ane the party involved didn't think much of it (remember Poject David?) But this has little to do with the matter at hand. I doubt that Thinstall would really want to do anything illegal -- this woul,d ruin their reputation, and would likely expose them to a copyright lawsuit(s). We can only level accusations after they do wrong. Why should we a priori think of them as guilty? I think that while Vitaliy has some firm moral (and otherwise) viewpoints, the Thinstall bashing of his was a bit much. C'mon, they just politely asked if anyone is interested in a job. What's wrong with that? If I were looking for winapi hackers, I'd ask here myself. Jeez. Cheers, Kuba
Re: Wine developers?
Friday, June 23, 2006, 9:51:28 AM, Kuba Ober wrote: On Wednesday 21 June 2006 21:24, Vitaliy Margolen wrote: Wednesday, June 21, 2006, 11:41:32 AM, Andreas Mohr wrote: Hi, On Wed, Jun 21, 2006 at 07:27:28PM +0200, Kai Blin wrote: I wouldn't necessarily judge the whole list by just two negative reactions. It's interesting to see that with my wine experience there might be jobs out there working on something similar. (Not that I'm interested right now, I'm still at university...) I'm sure you're aware that in every open source project, there's people who oppose commercial software development for philosophical reasons. proprietary please, not commercial. HUGE difference. I was talking more about nature of the job. I'm sure that lots of Wine code can leak into commercial product and wise versa. What's worse is that it already DID happen, ane the party involved didn't think much of it (remember Poject David?) But this has little to do with the matter at hand. I doubt that Thinstall would really want to do anything illegal -- this woul,d ruin their reputation, and would likely expose them to a copyright lawsuit(s). We can only level accusations after they do wrong. Why should we a priori think of them as guilty? I think that while Vitaliy has some firm moral (and otherwise) viewpoints, the Thinstall bashing of his was a bit much. C'mon, they just politely asked if anyone is interested in a job. What's wrong with that? If I were looking for winapi hackers, I'd ask here myself. Jeez. I'm sorry that my intentions were misinterpreted because of the bad choice of words on my part. I didn't want to sound that negative. What I wanted to say, is that the nature of the Wine (windows internals) and Thinstall (internal knowledge of windows) are some what close. So it's kind of a thin line that I'm sure neither side wants to cross. As for the job offers - I wish you good luck finding the right person for the job. And for a Wine hacker to finally be able to pay his/hers bills. IMHO the project's developer's mailing list is not the right place to send such offers. PS: Again this is all IMHO and in no way should represent opinions of anyone else. Vitaliy.
Re: Wine developers?
Jonathan Clark wrote: Judging by the two negative reactions Based on the expressive smiley in my posting, I'd hardly consider it negative. It was more of a well-meaning joke, but perhaps also one that told how your posting could be interpreted. I *would* find it interesting to know how much inspiration you guys find in the Wine codebase, though. Have you thought about collaborating with the Wine project instead of hiring people from it? Since Thinstall versus the Wine project are not exactly targeting the same markets, collaboration on API development could be fruitful for both parties. (Oh, and I'm not exactly a Wine developer either, so no reason to take my comments too seriously.)
RE: Wine developers?
Judging by the two negative reactions, apparently I didn't follow protocol for posting to the list and I want to apologize for that. I understand how it can look from a different perspective. I checked with the #wine-hackers channel first and those guys were very friendly. We had a great discussion and when I mentioned we were looking for developers they suggested I post here. Thanks for your time and consideration, Jonathan
Re: Wine developers?
* Jonathan Clark [EMAIL PROTECTED] [20/06/06, 23:35:26]: Judging by the two negative reactions, apparently I didn't follow protocol for posting to the list and I want to apologize for that. I understand how it can look from a different perspective. I checked with the #wine-hackers channel first and those guys were very friendly. We had a great discussion and when I mentioned we were looking for developers they suggested I post here. Thanks for your time and consideration, I wouldn't necessarily judge the whole list by just two negative reactions. It's interesting to see that with my wine experience there might be jobs out there working on something similar. (Not that I'm interested right now, I'm still at university...) I'm sure you're aware that in every open source project, there's people who oppose commercial software development for philosophical reasons. As for stealing developers, I think the terms of contract could make sure that the developer is free to work on wine in his spare time, but that's a thing for people interested in the job to take care of. The same people who proposed to post here will still back up that proposal, even if they don't speak up now. Cheers, Kai -- Kai Blin, (blin at gmx dot net) Is a person who blows up banks an econoclast?
Re: Wine developers?
Hi, On Wed, Jun 21, 2006 at 07:27:28PM +0200, Kai Blin wrote: I wouldn't necessarily judge the whole list by just two negative reactions. It's interesting to see that with my wine experience there might be jobs out there working on something similar. (Not that I'm interested right now, I'm still at university...) I'm sure you're aware that in every open source project, there's people who oppose commercial software development for philosophical reasons. proprietary please, not commercial. HUGE difference. As for those people even opposing commercial development: go wherever I don't need to see you ;) As for stealing developers, I think the terms of contract could make sure that the developer is free to work on wine in his spare time, but that's a thing for people interested in the job to take care of. Indeed. If the conditions are fine OSS-wise then I don't see a reason to complain. More offers is always a good thing :) Andreas Mohr
Re: Wine developers?
Wednesday, June 21, 2006, 11:41:32 AM, Andreas Mohr wrote: Hi, On Wed, Jun 21, 2006 at 07:27:28PM +0200, Kai Blin wrote: I wouldn't necessarily judge the whole list by just two negative reactions. It's interesting to see that with my wine experience there might be jobs out there working on something similar. (Not that I'm interested right now, I'm still at university...) I'm sure you're aware that in every open source project, there's people who oppose commercial software development for philosophical reasons. proprietary please, not commercial. HUGE difference. I was talking more about nature of the job. I'm sure that lots of Wine code can leak into commercial product and wise versa. As for those people even opposing commercial development: go wherever I don't need to see you ;) There are such people? If so, my guess would be 99.99% of them never wrote a line of code. Vitaliy
Wine developers?
Hello All, My name is Jonathan Clark, and I work with a team on a project that has some similarities with Wine. The project is called Thinstall (http://thinstall.com), and on first glance similarities may not be apparent. Thinstall allows Win32 applications to run (on Windows) from a network share or usb flash drive with zero install. It isn't meant to allow applications to run cross platform like wine, but it is similar in that it replaces the Windows loader for loading EXEs DLLs, doing things like mapping, imports, and thread/process management. It also replaces ~400 Win32 api functions in order to allow applications to run instantly in a sandbox so they don't need to touch the local filesystem or registry. Our approach is all in user mode so that applications can run under any login account without needing admin rights or drivers. Thinstall packages the entire application into a single EXE file and then tacks on it's runtime (300k on disk) so apps can be distributed and run as a single file that doesn't need to decompress to disk. The challenges in creating Thinstall are many of the same ones that Wine faces, achieving a high degree of compatibility in replacement functions means you need to be good at debugging and understanding the internals of Windows. Since most code can be run by multiple threads, it is also important to understand thread safety and have a lot of experience working through these types of issues. Thinstall is now about 6 years old and we are coming up on a version 3.0 release. Thinstall is a commercial product and everyone works full time with funding coming from our customers. Recently we've done fairly well financially and have the opportunity to try to take the product and company to the next level by hiring a couple of senior engineers. This brings me to why I'm posting here.. If you are experienced with Windows internals, have experience reimplementing Win32 APIs, and you are interested in some contract or full-time work please let me know. We are located in San Francisco, California (awesome town) and ideally I'd like to work with people locally. We can help with a move if needed. Otherwise, if you are outside of the USA - we could talk about doing something remotely. I hope to hear from you. Best Regards, Jonathan Clark P.S. As background info, I used to be heavily in the linux space when I co-founded a video game company Crack dot com which made the linux port of Doom Quake as well as developed the original titles Abuse and Golgotha. I have been aware of wine for a long long time and I'm impressed by the quality of work by all the developers and how far it has come. P.S.S. I subscribed in digest mode so if you reply to the list, keep in mind I won't see it until tomorrow.
Re: Wine developers?
Tuesday, June 20, 2006, 2:59:59 PM, Jonathan Clark wrote: Hello All, My name is Jonathan Clark, and I work with a team on a project that has I think it's a really really really rude to write to an open source project and offer such a work. Basically you are _stealing_ developers from the project. Because with your closed source project such developer will be prohibited from participating in the Wine project. Unless of course you want to open source your project and release it under at least GPL licence. Vitaliy.
Re: Wine developers?
It's up to individual developers to decide whether or not to work on a project that precludes them from contributing to particular OSS projects. It might be slightly off topic but there haven't been a lot of job offer emails to wine-devel lately or ever. Chris On Tuesday 20 June 2006 9:32 pm, Vitaliy Margolen wrote: Tuesday, June 20, 2006, 2:59:59 PM, Jonathan Clark wrote: Hello All, My name is Jonathan Clark, and I work with a team on a project that has I think it's a really really really rude to write to an open source project and offer such a work. Basically you are _stealing_ developers from the project. Because with your closed source project such developer will be prohibited from participating in the Wine project. Unless of course you want to open source your project and release it under at least GPL licence. Vitaliy.
Re: Wine developers?
Lots of open source developers probably still have day jobs. Maybe they're looking for a new one. Vitaliy Margolen wrote: Tuesday, June 20, 2006, 2:59:59 PM, Jonathan Clark wrote: Hello All, My name is Jonathan Clark, and I work with a team on a project that has I think it's a really really really rude to write to an open source project and offer such a work. Basically you are _stealing_ developers from the project. Because with your closed source project such developer will be prohibited from participating in the Wine project. Unless of course you want to open source your project and release it under at least GPL licence. Vitaliy.
Re: Wine developers?
Jonathan Clark wrote: replaces the Windows loader for loading EXEs DLLs, doing things like mapping, imports, and thread/process management. It also replaces ~400 Win32 api functions We're currently borrowing code from the Wine project... with funding coming from our customers. Recently we've done fairly well financially and have the opportunity to try to take the product and company to the next level by hiring a couple of senior engineers. This brings me to why I'm posting here.. ...which we're having good commercial success with, so now we'd like to knick a couple of developers from the project, too! Sign-up forms here. Or did I completely misread your posting? :-D
