April 2010 - Wine-Devel - list.winehq.org

Re: [PATCH 3/7] d3dx9_36: Beginning of constants parsing + tests (based on work from Luis Busquets)
by Henri Verbeet April 5, 2010

April 5, 2010

On 5 April 2010 10:30, Christian Costa <titan.costa(a)wanadoo.fr> wrote: > +inline ctab_constant* get_constant(D3DXHANDLE ptr) > +{ > + if (!ptr) return NULL; > + return (ctab_constant*)~(DWORD)ptr; > +} > + > +inline D3DXHANDLE get_handle(ctab_constant* ptr) > +{ > + return (D3DXHANDLE)~((DWORD)ptr); > +} These look like they would be problematic on 64-bit, does it really work like that?

2 1

Hello, All! Interested in GSoC
by Bradley Tucker April 5, 2010

April 5, 2010

Hello everyone, I am Bradley Tucker, a junior computer science major at Tennessee Tech University, and I am very interested in participating in the Google Summer of Code. I have a strong passion for developing video games, and it sounds like working with the Wine Project this summer would be incredibly helpful, informative, and fun. I'm not sure exactly what I'm supposed to do to get started, so I'll just tell you a little about me and what I'd like to do. First of all, I am primarily a Windows user who is trying learn more about Linux and all the wonderful things it can do. I have experience programming in C++ and Java, but I am a quick learner and would gladly become fluent in another language, if necessary. I do not have any experience working in an open-source community, but again, I am always ready to learn and to try new things. I would like to participate in the Google Summer of Code because I feel it will help me gain necessary skills and knowledge that will help me once I graduate, while benefiting all others who use open-source software. While I may not be the most qualified individual right now, I promise that if I am selected to work for the Wine Project this summer, I will quickly do whatever I can to become as qualified as possible. I am a sociable and easy-to-get-along-with sort of guy, but I am extremely determined and hard-working, and I will do whatever I can to help the project progress. As I said before, I am very interested in gaming, so naturally Wine is project that I believe I will thoroughly enjoy working on. Firstly, I would be very interested in improving or testing any Direct3D features. Testing and finding bugs for recent releases would be tremendously beneficial in helping me get ready for a career in the gaming industry. So, finding bugs and ways to optimize recent releases would probably be my top choice for working on a project with Wine. I also enjoy playing classic games as much as the latest releases. The suggested idea of "implementing DOS graphics modes more faithfully" is one I would find tremendously interesting and hopefully informative. I don't know enough about Wine yet to give many specifics, but I would gladly work on any bugs or features that my mentor would find most crucial. While these are the topics that stood out most to me, I would honestly be willing to help out in any area that could use my help. As I said, I don't know if this is the best way to introduce myself or if this is the best way to present the ideas I would like to possibly work on. But, here I am, willing and able to help in whatever ways you would like. My e-mail address is bradley-tucker(a)hotmail.com, so feel free to contact me whenever you please, with any questions or comments. I am a student with classes, so I may not be able to respond right away. Thanks, and I hope to working with you this summer! Bradley Tucker Computer Science Major Junior, Tennessee Tech University bradley-tucker(a)hotmail.com _________________________________________________________________ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID2…

1 0

Re: [PATCH 4/7] d3dx9_36: Implement D3DXGetImageInfoFromFileInMemory using WindowsCodecs (based on work from Tony Wasserka)
by Vincent Povirk April 5, 2010

April 5, 2010

> + CoUninitialize(); You should call this function only if your original CoInitializeEx call succeeded. It may fail in a multithreaded apartment (in which case WIC won't work either, but that's a bug), and in that case the uninitialize is not needed. Also, you seem to be leaving things uninitialized if you get an unrecognized container format or pixel format. That's probably not a good policy.

1 0

Re: [PATCH 1/2] amstream: Expose also IMultiMediaStream which is the base interface of IAMMultiMediaStream (patch from Qingchuan Wang)
by Henri Verbeet April 5, 2010

April 5, 2010

On 5 April 2010 10:55, Christian Costa <titan.costa(a)wanadoo.fr> wrote: > The proper way to do attribution is by adding an appropriate From: line to the patch, preferably by simply passing --author with the right information to git commit.

1 0

Re: [PATCH 6/7] d3dx9_36: Add stub for D3DXCreateTextureFromFileA
by Henri Verbeet April 5, 2010

April 5, 2010

On 5 April 2010 10:30, Christian Costa <titan.costa(a)wanadoo.fr> wrote: > + FIXME("(%p, %s, %p): stub\n", device, srcfile, texture); "srcfile" is an external string, this should use debugstr_a().

1 0

Re: [PATCH 2/7] d3dx9_36: Improve FIXMEs and TRACEs for surface
by Henri Verbeet April 5, 2010

April 5, 2010

On 5 April 2010 10:30, Christian Costa <titan.costa(a)wanadoo.fr> wrote: > @@ -71,7 +71,8 @@ HRESULT WINAPI D3DXGetImageInfoFromFileA(LPCSTR file, D3DXIMAGE_INFO *info) > LPWSTR widename; > HRESULT hr; > int strlength; > - TRACE("(void): relay\n"); > + > + TRACE("(%s, %p): relay\n", file, info); You should use debugstr_a() here (and in a few other places).

1 0

Re: user32/dialog.c: GetNextDlgTabItem returns hwndDlg if next item not found
by Dmitry Timoshkov April 5, 2010

April 5, 2010

"Mikhail Maroukhine" <mikolg(a)connectivegames.com> wrote: > user32/dialog.c: GetNextDlgTabItem returns hwndDlg if next item not found > Behavior checked on Windows XP Please add a test case for this. > + return retWnd ? retWnd : (hwndCtrl ? hwndCtrl : hwndDlg); Using an 'if' case would be more readable IMO. -- Dmitry.

1 0

[GSOC] dshow/gst branch rebased and commented
by Edward Hervey April 5, 2010

April 5, 2010

Hi all, I took some time this morning to rebase tdavenport's gst/dshow branch against current master and added my comments/reviews in the last commit. The branch can be found here : http://github.com/bilboed/wine/tree/tdaven-rebased I'm putting this out so that if any student is interested, he could carry on this work during GSOC. The current status is that using gstreamer as a backend for dshow has been proven to work within a very limited use-case. What remains: * Making it more efficient, flexible and lightweight (see all my comments) * Allowing it to automatically pick up whatever GStreamer element is available on the system and make it available through dshow. A good goal for example would be to make the various audio/video gstreamer sinks available through dshow (for example picking up the pulse sink), and the various audio/video decoders. Having it working with a native windows application (pick a player or an audio/video app using dshow) would be a must. Don't hesitate to ask questions/comments, Edward

2 1

re: GSoC WPKG and test.winehq.org
by Dan Kegel April 5, 2010

April 5, 2010

> Converting the wpkg scripts to appinstall doesn't > seem like that difficult of a task, mostly just time consuming. It's harder than it sounds to actually get a few useful app tests written. Plus there'll be some work writing up and fixing the bugs it uncovers. > That is why I thinking working on tying it into test.winehq.org is more worthy. > I still think tying appinstall and patchwatcher together would be > beneficial and allow people submitting patches to see where > regressions pop up in software, and to see > what new software works with each submitted patch. > Perhaps a project of implementing all of this and adding wpkg scripts would be accepted? Arjun Comar is going to propose something similar, but using Buildbot as the point of integration. - Dan

4 7

Re: Working on "DOS" VGA.
by Chris Ahrendt April 3, 2010

April 3, 2010

On 4/3/2010 11:34 AM, Alexandre Julliard wrote: > Stefan Dösinger<stefandoesinger(a)gmx.at> writes: > > >> Am 02.04.2010 um 02:08 schrieb chris ahrendt: >> >> >>> Just my 2 phennings worth on this... >>> Why reinvent the wheel... I would say instead of doing the emulator inside wine... or a JIT... why not have >>> wine intersept the call to start the vm86 mode.. and forks off and starts DOSEMU or whatever DOS box system is >>> configured.. That way wine doesnt have to worry about it... >>> >> Because you can mix modes in one executable. Take for example the >> average modern dos game: They start as real mode apps, then switch to >> a 32 bit protected mode dos extender(e.g. dos4gw.exe). I wouldn't be >> surprised if the app can transform itself into a Win16 app that tries >> to pop up a window. Wouldn't work well in Linux dosemu. >> > DOS apps can't do that. Pretty much the only thing you really have to > share is the filesystem, and it should be easy to configure DosBox to > mount ~/.wine/drive_c, and to invoke Wine when a DOS app starts a > Windows binary. > > There's no reason to replicate DosBox inside Wine. On the contrary, a > nice project would be to improve integration with an external DOS > emulator and then rip out the half-broken vm86 support from Wine. > > That is what I would think should be done... chris

1 0