RE: xcopy / cmd question (lack of real exe in system32)
Hello Jason, I'm just curious: xcopy.exe is an external program in Windows, but you want to make it a builtin command in Wine? Regards Alex -Original Message- [mailto:[EMAIL PROTECTED] On Behalf Of ext Ann Jason Edmeades If I now run wine xcopy, then it works (and gives a basic error for now), but it I run wine cmd, then xcopy I get file not found. As far as I can tell, cmd will only search the path for such a program and fails to find it. Should I add it to the fake dlls, which I think would cause a file to be created in system32, or how should cmd handle this situation as xcopy.exe.so isn't available on the path.
Re: Allow enabling/disabling Direct3D usage of GLSL in Winecfg
H. Verbeet wrote: On 22/03/07, Vit Hrachovy [EMAIL PROTECTED] wrote: Hi, according to thread 'WineCfg and DirectX options' at wine-devel, I'm proposing a patch for winecfg to allow enabling/disabling usage of GLSL for Direct3D applications rendering. Patch will add a checkbox into Graphics - Direct 3D section of Winecfg. IMO this doesn't belong in winecfg. Nevertheless, if you want to do this, you should change the resources for languages other than English as well. Hi, I've inspected Cs.rc and other .rc files and I've found that lots of them differ greatly from En.rc. Am I missing some process of notifying translators that En.rc has been changed? En.rc seems most up to date, so I've updated this as a reference one for translators. http://winehq.org/site/docs/winedev-guide/adding-languages states that translators should use En.rc for reference implementation. It looks like winecfg has a different interface for different languages due to this nature of locales implementation. I understand Your point, but as the .rc files varies so much, I'm not sure whether I'll break something if I modify the languages I'm not speaking. I can sync Cs.rc with actual En.rc, if it's enough to address your advice. Regards Vit This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Re: xcopy / cmd question (lack of real exe in system32)
I'm just curious: xcopy.exe is an external program in Windows, but you want to make it a builtin command in Wine? No, its already committed in the tree already as an external program (programs\xcopy). The installer I was fiddling with which caused me to write xcopy actually uses (effectively) cmd.exe /c xcopy. The fact I cant run a wine supplied program from within another portion of wine was what concerned me. I was trying to understand how wine locates it, given that CreateProcess doesnt find it (nor SearchPath). IF the answer is that we need fake dlls, we probably need to ensure we do it for any exe from the wine 'programs' branch. Jason
Re: xcopy / cmd question (lack of real exe in system32)
Jason Edmeades [EMAIL PROTECTED] writes: The installer I was fiddling with which caused me to write xcopy actually uses (effectively) cmd.exe /c xcopy. The fact I cant run a wine supplied program from within another portion of wine was what concerned me. I was trying to understand how wine locates it, given that CreateProcess doesnt find it (nor SearchPath). IF the answer is that we need fake dlls, we probably need to ensure we do it for any exe from the wine 'programs' branch. No, cmd.exe should be fixed to be able to run a builtin exe even if the file is not found in the path. CreateProcess is able to do that already, so it's probably just a matter of not bailing out when SearchPath fails. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [netapi32/tests] Use LoadLibrary where needed and skip
On Friday 23 March 2007 11:38, Paul Vriens wrote: access.c currently has fixed tests for 'Administrator'. This will obviously fail on systems with a different locale or system where Administrator has been renamed. (Added a FIXME). I'll be looking into that shortly. Thanks for the other fixes. Cheers, Kai -- Kai Blin, kai Dot blin At gmail Dot com WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpIwHKKAm79o.pgp Description: PGP signature
Re: wined3d: Implement support for projective textures in ps 2.0 and later
On 23/03/07, Fabian Bieler [EMAIL PROTECTED] wrote: +#define D3DSI_TEXLD_PROJECTED 0x0001 This should be called WINED3DSI_TEXLD_PROJECTED, and should be added to wined3d_private_types.h, together with the other WINED3DSI defines. Also, please add a comment that texldp always divides by the fourth component.
Re: WinRAR installer icon creation, and the Start Menu folder
On 3/22/07, Jan Zerebecki [EMAIL PROTECTED] wrote: On Thu, Mar 22, 2007 at 01:22:38PM -0500, Tom Spear wrote: Why, if we create folders like Desktop and My Documents, under the fake windows directory, do we not create a Start Menu folder? We do create it during wineprefixcreate. .wine/drive_c/windows/profiles/username/Start Menu Jan hmm. I looked in the shell32 source (0.9.33), and I don't see it in the function that creates the Desktop and My Documents and co folders, and its not getting created when I run wineprefixcreate. Should I open a bug? -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373from=power-email
Re: WinRAR installer icon creation, and the Start Menu folder
On 3/23/07, Tom Spear [EMAIL PROTECTED] wrote: On 3/22/07, Jan Zerebecki [EMAIL PROTECTED] wrote: On Thu, Mar 22, 2007 at 01:22:38PM -0500, Tom Spear wrote: Why, if we create folders like Desktop and My Documents, under the fake windows directory, do we not create a Start Menu folder? We do create it during wineprefixcreate. .wine/drive_c/windows/profiles/username/Start Menu Jan Ok I dont know WTF is going on or why it didnt work before but when I cleaned everything again, this time it was created properly. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373from=power-email
Winebot
Hi all, first thanks for a lot of comments. I interpret this as a creative discussion helping to shape WINE project attitude to Winebot and Winebot project itself. I'll let Karl Lattimer to state his attitude with his Wine-Doors project. In the following words, I'm going to discuss my personal point of view, as I'm representing Winebot project. I'll first summarize some points extracted from the previous discussion: -- 1. My goal in writing Winebot is to help Wine succeed 2. I pledge to use only the bare minimum of native DLLs in any Winebot recipe 3. I pledge to remove native DLLs from Winebot recipes as soon as Wine fixes the bugs that keep Wine's DLLs from being sufficient for that app 4. I will report bugs to the Wine project in the course of working on Winebot 5. Installation of basic compatibility programs sounds like it would clash with only use the bare minimum of native DLLs / hacks in any Winebot recipe. Winebot shouldn't install anything that the application does not need. 6. I will help Wine by writing not just Winebot recipes, but also basic application regression test scripts 7. If developers working on projects such as Wine-Doors contributed to Wine, then the bugs would be fixed even faster. 8. If you are making it extremely easy for users to run with native dlls and hacky workarounds, then you are hurting Wine. Wine is still beta, and we need as much testing and bug reporting as possible. In short, you leech off the hard work of all the Wine developers and give nothing back in return (quite the opposite in fact). -- Analyzing the objections written in discussion, I've found that you are missing the following: a) Clear statement, which will specify Winebot project's goals and attitude to its parent project - WINE. Sort of manifest. b) Results - working and actively supported regression testing scripts suite. c) Forwarding bugs and list of 'unclean' fixes to bugs.winehq.org. As I'm Debian and Ubuntu user I actively borrow knowledge from the Debian project. Each Winebot package shall have a maintainer responsible for package quality and for interfacing with WINE project(AppDb, Bugzilla, Testing, Fixing). Every official Winebot maintainer will be bound by sort of Winebot manifest stating the Winebot project's attitude to WINE project. I'll write the manifest (a),(c) and post it onto Winebot Wiki. To create (b) I gladly accept any input to create a regression test repository, would You be so kind and point me to some list of programs / test miniprograms to make a reference implementation? -- 1. My goal _is_ to help Wine succeed. Hours I'm investing in Winebot are hours I'm spending on learning Wine. Recent discussion about missing reg.exe implementation originated from work on Winebot. I'm application maintainer on AppDb. I'm testing application compatibility on WINE versions back to 0.9.9. I've written Winebot especially to make the testing easier. I often install and uninstall Windows programs from WINE bottles, I'm used to bottles (WINEPREFIX) system, too. Having the installation of programs (and their dependencies) scripted is the first step for making automated testing. 2., 3., 4. All Winebot packages should install only minimum neccessary dependencies and their install scripts should be ideally only using normal application Windows installer. Any hacks above will be reported (in case they weren't reported already) to WINE bugzilla. 5. That's a relict from winetools project. 'bottle initialization' will be removed soon as unnecessary. Working package dependencies allow to reconstruct every step of setup and every 'hack' in used packages. 6. Yes, I'm planning to set up a regression tests repository for WINE (and for Winebot too). As Winebot is using AutoHotKey system for installer automation, it can also run programs, check window properties and contents, click on specified button or areas, etc. For more information, see http://www.autohotkey.com 7. Actually I consider my Winebot work is a work for WINE project and WINE users. If I find some error in WINE, I report. Same when I need new functionality. If I'm capable, I'm trying to discuss, implement and send a patch for WINE. Actually Winebot could help more WINE developers with testing, with testing environment setup and with duplicating bug cases, IMHO. 8. User simply wants his application to work. Package maintainer, who prepares the package, should interface with WINE developers whenever he spots a glitch. Package maintainer goes with new WINE versions and prepares a package for each WINE version. Package maintainer is therefore dedicated regular WINE tester and bug reporter. Package maintainer also filters user feedback to create a useful bug report, probably with a patch proposal in ideal situation.
Re: WinRAR installer icon creation, and the Start Menu folder
On Fri, Mar 23, 2007 at 08:29:03AM -0500, Tom Spear wrote: hmm. I looked in the shell32 source (0.9.33), and I don't see it in the function that creates the Desktop and My Documents and co folders, and its not getting created when I run wineprefixcreate. Should I open a bug? At some point SHGetFolderPathW should get called with it and that should create it... Jan
Re: [1/7] - [6/7] wined3d: Implement linear fog with pixel shader and some other patches
What apps exactly did you tested ? Best regards Shadow Dnia czwartek, 22 marca 2007, Mirek napisał: Perfect work!! nVidia VertexMorph demo is fixed and some other games too. Mirek -- -- Registered User No 397465 Linux 2.6.20-gentoo i686 AMD Athlon(tm) XP 2800+ http://www.spreadkde.org/try_kde --
Re: Review of wine/crossover
On Wed, Mar 21, 2007 at 11:07:22AM -0700, Dan Kegel wrote: Another jouralist tries linux article. This one's pretty good. http://www.computerworld.com/action/article.do?command=viewArticleBasicarticleId=9013280 There is also a comment (page4 of comments) that the Windows app Quickbooks is a showstopper for installing linux in small enterprises. regards Richard A Lough
Re: Add d3drmdef.h header file - try 4
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote: Fix the D3DRMAPI definitions (Dimitry's Comments) Fix the inclusion of d3dtypes.h (Francois' Comments) Where other comments has gone, into a black hole? Changelog Add d3drmdef.h header file, required for d3drm implementation This version is absolutely broken and unusable. -- Dmitry.
Is anyone using wrc --verify-translation?
For my translations statistics (http://pf128.krakow.sdi.tpnet.pl/wine-transl/) I use a patched wrc that has a different output for wrc --verify-translation. Could I send this patch to wine-patches or is there someone other using wrc --verify-translation and would be upset if the format changes (in such a case I could try to keep both formats lauched by different options)? I'm asking because I've contacted Jeremy Newman about integrating the statistics with WineHQ and having the patch in the official tree would probably simplify the maintenance. Mikolaj Zalewski
re: Winebot
Vit wrote: I'll write the manifest (a),(c) and post it onto Winebot Wiki. Cool... where is that? I gladly accept any input to create a regression test repository, would you be so kind and point me to some list of programs / test miniprograms to make a reference implementation? I'd be glad to. I, Lei, and Nigel are just getting that going, and will be in touch via email. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Icon for wine
I created an svg version of wine's logo and then I created some icons for the wine applications based on wine's logo and tango's icons. wine-regedit.svg is based on a clipart found at openclipart.org: http://openclipart.org/media/files/nicubunu/2842 (license:public domain) They are temporarily hosted at http://200.181.205.134/wine/ Debdiff against the ubuntu's package to update the .desktop files is in this url too. Hope you enjoy. Marcelo Shima
Re: Road to 1.0
Tom Wickline [EMAIL PROTECTED] writes: I see Wine 1.0 as a set of features that AJ has decided upon, once the feature set is in the tree then a feature freeze will go onto effect.. Then one to six months of only bug fixes. Then wala 1.0 is born. At the last Conf if memory serves me correctly there was mention of a feature freeze happening sometime early this year. And I would only guess to say the release notes after the freeze would read X amount of bugs were fixed in this release, as no new features would be implemented. That's still the plan, yes. I'm mostly waiting for the games support to stabilize; the other main areas, office apps and installers, both seem in good enough shape at this point. I'm also hoping we can make some progress on the x11drv factorisation before the freeze, so that we don't need to change the interface too much to add the quartz driver later on, we'll see how that goes. And if we delay it a bit more maybe we can slip in Safedisc support too... -- Alexandre Julliard [EMAIL PROTECTED]
Re: Road to 1.0
On Friday 23 March 2007 20:26, Alexandre Julliard wrote: Tom Wickline [EMAIL PROTECTED] writes: I see Wine 1.0 as a set of features that AJ has decided upon, once the feature set is in the tree then a feature freeze will go onto effect.. Then one to six months of only bug fixes. Then wala 1.0 is born. That's still the plan, yes. I'm mostly waiting for the games support to stabilize; the other main areas, office apps and installers, both seem in good enough shape at this point. I'm also hoping we can make some progress on the x11drv factorisation before the freeze, so that we don't need to change the interface too much to add the quartz driver later on, we'll see how that goes. And if we delay it a bit more maybe we can slip in Safedisc support too... Just please don't freeze during Summer of Code. I had that while trying to get my 2005 work in, and that's really depressing. Cheers, Kai -- Kai Blin, kai Dot blin At gmail Dot com WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpQHJA2pDjPm.pgp Description: PGP signature
Anyone working on XKB support for Wine (or any other Keyboard language detection enhancements)?
Hi all, The current keyboard detection and setting code is based on the traditional method of setting a keyboard in X11. It misdetects most any language that carries a US keyboard as the first group. While major work on other areas of Wine means that most programs today don't really care about that, it still confuses the $*([EMAIL PROTECTED]$ out of Word. It also has some pretty serious BiDi editing implications. I'm looking into replacing that with code based on the XKB X11 extension, today supported with any quasi reasonable X server. This should totally eliminate the guesswork done through keyboard change detection in wine today. The main question is this - is anyone today already working on this? Thanks, Shachar
Re: Road to 1.0
Yea, I agree with what you said, I didn't mean for my message to sound like people were doing anything blatantly wrong, the fact is though, if we like them or hate them from a development standpoint, people love these work arounds as users, and, it's just the evolution of the community that will make things like this. For the user it's make it make it work quick, more so than get fixes into the tree. Since we can't just stop the projects, which I don't think we would *really* want to, working aorund them is the best bet. Maybe talk with the maintainers of these so called Wine GUIs, and have them implement methods of sending in reports. Not to mention that we could have some kind of an unexpected kill catch to compile bugreports automatically, and tell the user how to go about submitting it, or even do it for them, to some degree we could have information on individual fix mes sent as well, you could imagine seeing which 'fixme' was spit out the most, then focusing on it. Things like that would not only help users get to the devs, but help the devs stay on track of whats best needed, for those that focus on the general need, rather than the this doesn't work for me, I'll fix it way, which isn't so bad in itself. I don't know... I'm an idealist =] On 3/23/07, James Hawkins [EMAIL PROTECTED] wrote: On 3/22/07, Bryan Haskins [EMAIL PROTECTED] wrote: If you are making it extremely easy for users to run with native dlls and hacky workarounds, then you are hurting Wine. Wine is still beta, That's true... and people technically should only be using wine for the pure sake of testing and helping fix usage. LEt's be honest, very few use it for that, they just want it to work, they use wine for the use the Devs want out of 1.0. Saying to someone that because it doesn't work by default, we're not going to let you use it, or in general make it hard for them defeats the goal of the *actual program*, No one here says they can't use Wine if their app doesn't work, and we're certainly not trying to make it harder for them if that is the case. The argument is irrelevant though, as it doesn't follow the original question, Does my development of Wine-Doors hurt Wine. Joe XYZ wants to play Oblivion, He Finds it doesn't work! He looks around and sees that if he does a lot of various things it will work *okay*, Joe XYZ does them. Joe XYZ had no intention of ever submitting bugs at all, is this bad? Hell yes it is. We should educate at how important it is for a program like Wine to have nice detailed Bug Tracking, but at the same time, can you blame him for just wanting it to work, easily? As long as the user, at some point, realized, hey this doesn't work out of the box, the job is done to some degree. The optimal outcome of this scenario is that Joe XYZ reports his problems running Oblivion to the Wine development community using bugzilla. The Wine development community then fixes these bugs, leaving Joe XYZ very satisfied with Wine. The next possible outcome is that it takes a little while for the bugs to be fixed, though they'll be fixed at some point, but we do try our hardest. If developers working on projects such as Wine-Doors contributed to Wine, then the bugs would be fixed even faster. To summarize, If a user never was going to report things, that's bad, he should be educated, but at the same time, if he still wouldn't, shouldn't it be our job as the community to make it easy for him? Make it easy for him to report the bugs? Yea we should make it as easy as possible. This goes back to the WineTools thing... that was bad though, even though at face it seems the same... in reality people were starting to just say Install Wine, then you *need* to install winetools and run the base install thing, without ever actually saying HEY! Newbs! This wont work so you should install zyx to make it work as a temporary solution until such a time as it's fixed in the wine tree. OR something similar. Wine-Doors is the exact same thing as WineTools from the perspective of the Wine developers. I guess my point is two fold: -The user needs to know about bug reporting. Definitely, and we're doing a good job at it so far. -The user needs to know what it means for something to not work 'out-of-the-box', and what exactly a 'dirty little hack' or the like is. Users know when things don't work out-of-the-box, whether they know what the term means or not, and we wouldn't have to worry about a user knowing what a 'dirty little hack' is if projects like Wine-Doors didn't exist. -- James Hawkins -- Cheers, Bryan
Re: Winebot
Wow You rpetty much leave us with nothing to complain about... if you truly stick to that, and help users, while still making sure you give the Devs word in their stead... It sounds like a sweet deal. On 3/23/07, Vit Hrachovy [EMAIL PROTECTED] wrote: Hi all, first thanks for a lot of comments. I interpret this as a creative discussion helping to shape WINE project attitude to Winebot and Winebot project itself. I'll let Karl Lattimer to state his attitude with his Wine-Doors project. In the following words, I'm going to discuss my personal point of view, as I'm representing Winebot project. I'll first summarize some points extracted from the previous discussion: -- 1. My goal in writing Winebot is to help Wine succeed 2. I pledge to use only the bare minimum of native DLLs in any Winebot recipe 3. I pledge to remove native DLLs from Winebot recipes as soon as Wine fixes the bugs that keep Wine's DLLs from being sufficient for that app 4. I will report bugs to the Wine project in the course of working on Winebot 5. Installation of basic compatibility programs sounds like it would clash with only use the bare minimum of native DLLs / hacks in any Winebot recipe. Winebot shouldn't install anything that the application does not need. 6. I will help Wine by writing not just Winebot recipes, but also basic application regression test scripts 7. If developers working on projects such as Wine-Doors contributed to Wine, then the bugs would be fixed even faster. 8. If you are making it extremely easy for users to run with native dlls and hacky workarounds, then you are hurting Wine. Wine is still beta, and we need as much testing and bug reporting as possible. In short, you leech off the hard work of all the Wine developers and give nothing back in return (quite the opposite in fact). -- Analyzing the objections written in discussion, I've found that you are missing the following: a) Clear statement, which will specify Winebot project's goals and attitude to its parent project - WINE. Sort of manifest. b) Results - working and actively supported regression testing scripts suite. c) Forwarding bugs and list of 'unclean' fixes to bugs.winehq.org. As I'm Debian and Ubuntu user I actively borrow knowledge from the Debian project. Each Winebot package shall have a maintainer responsible for package quality and for interfacing with WINE project(AppDb, Bugzilla, Testing, Fixing). Every official Winebot maintainer will be bound by sort of Winebot manifest stating the Winebot project's attitude to WINE project. I'll write the manifest (a),(c) and post it onto Winebot Wiki. To create (b) I gladly accept any input to create a regression test repository, would You be so kind and point me to some list of programs / test miniprograms to make a reference implementation? -- 1. My goal _is_ to help Wine succeed. Hours I'm investing in Winebot are hours I'm spending on learning Wine. Recent discussion about missing reg.exe implementation originated from work on Winebot. I'm application maintainer on AppDb. I'm testing application compatibility on WINE versions back to 0.9.9. I've written Winebot especially to make the testing easier. I often install and uninstall Windows programs from WINE bottles, I'm used to bottles (WINEPREFIX) system, too. Having the installation of programs (and their dependencies) scripted is the first step for making automated testing. 2., 3., 4. All Winebot packages should install only minimum neccessary dependencies and their install scripts should be ideally only using normal application Windows installer. Any hacks above will be reported (in case they weren't reported already) to WINE bugzilla. 5. That's a relict from winetools project. 'bottle initialization' will be removed soon as unnecessary. Working package dependencies allow to reconstruct every step of setup and every 'hack' in used packages. 6. Yes, I'm planning to set up a regression tests repository for WINE (and for Winebot too). As Winebot is using AutoHotKey system for installer automation, it can also run programs, check window properties and contents, click on specified button or areas, etc. For more information, see http://www.autohotkey.com 7. Actually I consider my Winebot work is a work for WINE project and WINE users. If I find some error in WINE, I report. Same when I need new functionality. If I'm capable, I'm trying to discuss, implement and send a patch for WINE. Actually Winebot could help more WINE developers with testing, with testing environment setup and with duplicating bug cases, IMHO. 8. User simply wants his application to work. Package maintainer, who prepares the package, should interface with WINE developers whenever he spots a glitch. Package maintainer goes with new WINE versions and prepares a package for each WINE
RE: xcopy / cmd question (lack of real exe in system32)
The installer I was fiddling with which caused me to write xcopy actually uses (effectively) cmd.exe /c xcopy. The fact I cant run a wine supplied program from within another portion of wine was what concerned me. I was trying to understand how wine locates it, given that CreateProcess doesnt find it (nor SearchPath). IF the answer is that we need fake dlls, we probably need to ensure we do it for any exe from the wine 'programs' branch. No, cmd.exe should be fixed to be able to run a builtin exe even if the file is not found in the path. CreateProcess is able to do that already, so it's probably just a matter of not bailing out when SearchPath fails. Unfortunately I need to know if it's a console app or not, and hence call FindExecutable followed by SHGetFileInfo. These don't seem to report anything on the internal programs so I couldn't tell whether to wait for it to complete (eg xcopy) or let it run (eg notepad). I'm patching it to assume worse case (run it synchronous) and just wait, unless you have any other suggestions, working on the theory this is a very rare case. Jason
Undocumented function syssetup.dll.SetupQueryRegisteredOsComponent
Any suggestions as to how to discover the prototype of the apparently undocumented function syssetup.dll.SetupQueryRegisteredOsComponent ? It seems to be needed to install mdac-2.8. ( http://bugs.winehq.org/show_bug.cgi?id=5824 ) - Dan
Re: Winebot
Will winebot be a win32 app or a linux app? Making it a win32 app and developing it on Windows would probably reveal more Wine bugs. Looking for earth-friendly autos? Browse Top Cars by Green Rating at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/
SoC Idea: Improve video support
I really want to participate in Google's Summer of Code, but I realize I don't have much time left to find a suitable project. What I am thinking of is to improve Wine's capability of playing videos in games, first by fixing mciavi so it can play the Worms 2 intro films (bug 4256), and then hopefully progessing to fixing bugs in quartz/devenum, like crashes in Worms Armageddon or playback in WMP9. Is this too ambitious considering that I don't really have much experience with C and Wine? The closest I have gotten is some patches for Wine's WordPad implementation. Regards, Alexander N. Sørnes
SoC idea: Tablet PC support (was: pressure sensitive tablet support)
On 3/21/07, Dan Kegel [EMAIL PROTECTED] wrote: While looking around for a project idea, I noticed that people are starting to ask for pressure sensitive tablet support in Photoshop on Wine. Seems like it could be a fun project for some Summer of Code student. Update: wintab32 is already implemented in Wine, but there's a new API being pushed by Microsoft for Tablet PC applications. So the idea is instead Get Tablet PC applications working on Wine, focusing on Tablet PC apps that offer pressure sensitivity, say. (I thought that FIrefox's GeckoTip extension used the new tablet PC APIs, but after looking at the source, I'm not so sure... I'm sure there are lots of good demo apps somewhere.) This assumes that Tablet PC apps don't yet work on Wine. I haven't tried... the place to start is probably to get the Tablet PC SDK (a free download if you have Windows) and start playing with it. - Dan
Tablet PC and Summer of Code in Ubuntu
Hi, I just wanted to call to the Ubuntu list's attention that there is also a discussion of getting tablet PC support into Wine. Developer Dan Kegel even suggested it as a Summer of Code project. I encourage Charlotte (or anyone else interested in tablet PC support) to also give the winehq list a try - they might even help mentor you. Also, if your summer of code project seems to help multiple Google-sponsored projects (eg Ubuntu and Wine), it's more likely to be approved :) Thanks, Scott Ritchie From the wine-devel mailing list: Re: SoC idea: Tablet PC support (was: pressure sensitive tablet support) On Fri, 2007-03-23 at 18:57 -0700, Dan Kegel wrote: On 3/21/07, Dan Kegel [EMAIL PROTECTED] wrote: While looking around for a project idea, I noticed that people are starting to ask for pressure sensitive tablet support in Photoshop on Wine. Seems like it could be a fun project for some Summer of Code student. Update: wintab32 is already implemented in Wine, but there's a new API being pushed by Microsoft for Tablet PC applications. So the idea is instead Get Tablet PC applications working on Wine, focusing on Tablet PC apps that offer pressure sensitivity, say. (I thought that FIrefox's GeckoTip extension used the new tablet PC APIs, but after looking at the source, I'm not so sure... I'm sure there are lots of good demo apps somewhere.) This assumes that Tablet PC apps don't yet work on Wine. I haven't tried... the place to start is probably to get the Tablet PC SDK (a free download if you have Windows) and start playing with it. - Dan
Re: SoC Idea: Improve video support
Alexander Nicolaysen Sørnes [EMAIL PROTECTED] wrote: I really want to participate in Google's Summer of Code, but I realize I don't have much time left to find a suitable project. What I am thinking of is to improve Wine's capability of playing videos in games, first by fixing mciavi so it can play the Worms 2 intro films (bug 4256), and then hopefully progessing to fixing bugs in quartz/devenum, like crashes in Worms Armageddon or playback in WMP9. Is this too ambitious considering that I don't really have much experience with C and Wine? The closest I have gotten is some patches for Wine's WordPad implementation. Very limited win32 programming experience might be a problem. If you intend to fix the problems with AVI file playback you should be prepared to fix wide range of things: winmm, msvf32, mciavi32 and any codecs involved. If you plan to look at the WMP9 playback problems that goes further to quartz.dll and OLE interfaces. -- Dmitry.
Re: Undocumented function syssetup.dll.SetupQueryRegisteredOsComponent
Dan Kegel [EMAIL PROTECTED] wrote: Any suggestions as to how to discover the prototype of the apparently undocumented function syssetup.dll.SetupQueryRegisteredOsComponent ? Perhaps installing native MSI and running with +relay,+snoop may shed some light, be prepared to decipher amount and the meaning of arguments by looking a the function args dumped by +snoop. -- Dmitry.
Re: netapi32/test: [1/5] Test the username and password length limits.
Kai Blin [EMAIL PROTECTED] wrote: +usri.usri1_name = (LPWSTR) sTooLongName; +usri.usri1_password = (LPWSTR) sTestUserOldPass; Just drop the 'const' modifier for the declared strings, don't use casts. There was a lot of efforts lately put into fixing Wine to compile cleanly with -Wcast-qual turned on, please fix the code while you are at it. -- Dmitry.
Re: netapi32: [2/5] Implement NetUserAdd with a dummy user database.
Kai Blin [EMAIL PROTECTED] wrote:
+if(!su)
+{
+status = NERR_InternalError;
+goto user_add_error;
+}
+
+if(lstrlenW(ui-usri1_name) LM20_UNLEN)
+{
+status = NERR_BadUsername;
+goto user_add_error;
+}
+
+/*FIXME: do other checks for a valid username */
+lstrcpyW(su-user_name, ui-usri1_name);
+
+if(lstrlenW(ui-usri1_password) PWLEN)
+{
+/* Always return PasswordTooShort on invalid passwords. */
+status = NERR_PasswordTooShort;
+goto user_add_error;
+}
'break' would work just fine instead of 'goto' in all these places.
--
Dmitry.
