March 2009 - Wine-Devel - list.winehq.org

Re: SoC: JavaScript implementation

by Piotr Caban

On Monday 30 March 2009 22:21:32 Reece Dunn wrote: > > - Look at Wine jscript.dll related bugs. > > These would be: 15432, 15582, 16208, 16594 and 17152. I'm not sure if > > they are JScript or MSHTML bugs yet as they require deeper analyze. I > > will fix their JScript part of problem. > > You might also want to look at 13459 ("Oberon game launcher (incl. > buttons) does not work"). This is related to 16594 ("Oberon game > launcher does not show the buttons to launch the game."). > > In the original 13459, wine would render the buttons (but would render > them funny), but they were unusable - that is clicking on them did > nothing. Since the commit located in 16594, only the background is > displayed (hence them being different defects). > > It would be nice to have this working, as this is the only thing > holding up Oberon games from working (well, around 50% of them, anyway > :) ). Thanks for pointing it out. I've missed 13459 because there was no evidence that it's JavaScript related. I will surely look at it. > > - Fix W3School (http://www.w3schools.com/js/default.asp) JavaScript > > examples. > > These seem to be a nice tests for me. They test commonly used APIs in > > real life scenarios. I believe that if these tests work, most web sides > > should work as well. > > This is a good idea. I also wonder how we can test the mshtml > DOM/scripting? I suspect that this is where most applications will > trip up. (Unless they are hitting a jscript bug first!) MSHTML currently uses Gecko JavaScript engine as well as DOM implementation for this site, so it will work the same way as it does on Firefox. > > - Test complex web pages > > Pages like GMail or Google Office would be really cool to have working > > with our JavaScript. Unfortunately I'm afraid that it may be too much > > work for SoC to fix them. I'd like to do some testing and find some > > complex web pages that I could use as tests. > > These are also likely to have issues when manipulating/navigating html > pages using the mshtml DOM API - i.e. the HTML DOM referenced in > http://www.w3schools.com/htmldom/dom_reference.asp. That's why I plan to use native IE for testing. This way I won't have to care about DOM implementation and I will be able to concentrate on JavaScript. > > If someone has any more ideas about tests I'm open for suggestions. > > You might want to try adding some JSON ("Java Script Object Notation") > examples - http://www.json.org/. The website even includes some JSON > parsers released under the Public Domain! They would make interesting > stress tests. > > Also, if you are feeling adventurous, there are some ray tracing > examples written in JavaScript! > http://www.chromeexperiments.com/detail/javascript-canvas-raytracer/ > (the link says that it is out of bandwidth!) > NOTE: There are several (now closed) Firefox bugs that contain various > forms of this, which can be found on bugzilla - the Firefox bugzilla > site is being slow for me, so I cannot look up the specific bugs at > the moment. > > And more generally http://www.chromeexperiments.com/browse/. > > You might also want to look at some of the javascript benchmark suites > like SunSpider and the V8 testsuite. This are nice ideas, however after testing with a few different test sites, I decided that w3school would be the best. I may go back to others when it's done. Raytracers are not really interesting, because they don't use much APIs, so they test only core engine performance. The same applies to most of Firefox tests that I found in their source tree. The main problem with running V8 testsuite is that we want to be compatible with MS JScript implementation. This tests show the right implementation :-) Thanks, Piotr

March 30, 2009

Re: GSoC: Improving DOS graphics

by Ricardo Filipe

2009/3/29 Daniel Kraft <d(a)domob.eu> > Hi, > > I would be interested in working on WINE for Google Summer of Code (as I > would like to get into WINE and learn more about it from the developer's > side of view; I imagine this is a very educational and interesting > experience in addition to being simply an interesting free software project > to work on). > > On the ideas list is a project about improving handling of DOS graphics > mode, this sounds interesting to me. I've got good experience with C, C++ > and other programming languages as well as programming in general, but so > far no knowledge at all about WINE apart from using it. > > Do you think this would be a good project to apply for and get into WINE? > (Thus both useful for the community as well as a good point for me without > WINE experience so far.) > > Regarding free software in general, I've already worked with some projects > including Mozilla and GCC, so I should be familiar with standard development > practices involved. > > Thank you very much, > Daniel > i for one would love to see this part of wine advance. i think it can even be too much for a SoC, it's not that easy of a task, mostly because there's not as good a documentation as for regular .dlls. i don't have much info on the subject but i'd suggest you check Jeremiah Fletchinger's patches that are not yet submitted and improve them if you decide to take this role, as a first task. i bet there are some people around who can give you more hints on what to do and a good mentor :)

March 30, 2009

Re: rpcrt4: Compile in RPC over HTTP support even if HAVE_SOCKETPAIR is not defined.

by Rob Shearman

2009/3/30 Alexandre Julliard <julliard(a)winehq.org>: > Rob Shearman <robertshearman(a)gmail.com> writes: > >> socketpair is only needed for the server functions for ncacn_ip_tcp. >> The tower implementation that ncacn_http and ncacn_ip_tcp share >> doesn't depend on it. > > It doesn't need socketpair, but it needs getaddrinfo and friends so it > still won't build on Mingw, that's why I disabled the whole thing. We > could put that part inside a #ifdef HAVE_GETADDRINFO instead, but the > end result would be the same. Ok, thanks for the clarification. I'll test building with Mingw before I submit any further patches along the same theme. -- Rob Shearman

March 30, 2009

Re: rpcrt4: Compile in RPC over HTTP support even if HAVE_SOCKETPAIR is not defined.

by Alexandre Julliard

Rob Shearman <robertshearman(a)gmail.com> writes: > socketpair is only needed for the server functions for ncacn_ip_tcp. > The tower implementation that ncacn_http and ncacn_ip_tcp share > doesn't depend on it. It doesn't need socketpair, but it needs getaddrinfo and friends so it still won't build on Mingw, that's why I disabled the whole thing. We could put that part inside a #ifdef HAVE_GETADDRINFO instead, but the end result would be the same. -- Alexandre Julliard julliard(a)winehq.org

March 30, 2009

Re: SoC: JavaScript implementation

by Reece Dunn

2009/3/30 Piotr Caban <piotr.caban(a)gmail.com>: > Hi, > > I'm planning to participate in Google Summer of Code this year. I was > thinking about working on recently added jscript.dll implementation. Its > engine looks almost complete, but I can see that there are many > unimplemented APIs. That's what I'd like to improve. Yay! :D > - Look at Wine jscript.dll related bugs. > These would be: 15432, 15582, 16208, 16594 and 17152. I'm not sure if > they are JScript or MSHTML bugs yet as they require deeper analyze. I > will fix their JScript part of problem. You might also want to look at 13459 ("Oberon game launcher (incl. buttons) does not work"). This is related to 16594 ("Oberon game launcher does not show the buttons to launch the game."). In the original 13459, wine would render the buttons (but would render them funny), but they were unusable - that is clicking on them did nothing. Since the commit located in 16594, only the background is displayed (hence them being different defects). It would be nice to have this working, as this is the only thing holding up Oberon games from working (well, around 50% of them, anyway :) ). > - Fix W3School (http://www.w3schools.com/js/default.asp) JavaScript > examples. > These seem to be a nice tests for me. They test commonly used APIs in > real life scenarios. I believe that if these tests work, most web sides > should work as well. This is a good idea. I also wonder how we can test the mshtml DOM/scripting? I suspect that this is where most applications will trip up. (Unless they are hitting a jscript bug first!) > - Test complex web pages > Pages like GMail or Google Office would be really cool to have working > with our JavaScript. Unfortunately I'm afraid that it may be too much > work for SoC to fix them. I'd like to do some testing and find some > complex web pages that I could use as tests. These are also likely to have issues when manipulating/navigating html pages using the mshtml DOM API - i.e. the HTML DOM referenced in http://www.w3schools.com/htmldom/dom_reference.asp. > If someone has any more ideas about tests I'm open for suggestions. You might want to try adding some JSON ("Java Script Object Notation") examples - http://www.json.org/. The website even includes some JSON parsers released under the Public Domain! They would make interesting stress tests. Also, if you are feeling adventurous, there are some ray tracing examples written in JavaScript! http://www.chromeexperiments.com/detail/javascript-canvas-raytracer/ (the link says that it is out of bandwidth!) NOTE: There are several (now closed) Firefox bugs that contain various forms of this, which can be found on bugzilla - the Firefox bugzilla site is being slow for me, so I cannot look up the specific bugs at the moment. And more generally http://www.chromeexperiments.com/browse/. You might also want to look at some of the javascript benchmark suites like SunSpider and the V8 testsuite. > For testing JavaScript on web pages I'm planning to use IE working on > Wine with built-in jscript.dll. This way I will be able to test > jscript.dll on web pages that is currently impossible to do with Wine > MSHTML and iexplore.exe. > > What do you think about this idea? Sounds good. - Reece

March 30, 2009

Re: 16bit code generation

by King InuYasha

On Mon, Mar 30, 2009 at 2:47 PM, David Laight <david(a)l8s.co.uk> wrote: > On Sun, Mar 29, 2009 at 06:23:53PM -0500, King InuYasha wrote: > > > > Unfortunately, at the moment it really is the best we have. AFAIK, there > > isn't any other FOSS compiler that can build 16-bit DOS/Win16 > applications. > > Unless someone was actually willing to figure out how to make GCC be able > to > > target Win16 (not likely) or write a whole new compiler toolchain to > target > > Win16/DOS, there really isn't anything else left to use. > > Will 'Bruce's C Compiler' target DOS/Win 16 ? > > David > > -- > David Laight: david(a)l8s.co.uk > Well, I stand corrected, Bruce's C Compiler will target DOS, but it doesn't look like it targets Win16, since it targets only DOS COM executables, not the DOS NE executable type also required (NE type is the one used in Win16 which is different from DOS COM type).

March 30, 2009

Re: [1/6] WineD3D: Merge index buffers into base buffers

by Henri Verbeet

2009/3/30 Stefan Dösinger <stefan(a)codeweavers.com>: > - hr = IWineD3DDevice_CreateBuffer(This->wined3d_device, &wined3d_desc, > - (IUnknown *)object, &object->wined3d_buffer); > + hr = IWineD3DDevice_CreateBuffer(This->wined3d_device, desc->ByteWidth, > + desc->Usage, 0, WINED3DFMT_UNKNOWN, WINED3DPOOL_MANAGED,· > + &object->wined3d_buffer, 0, (IUnknown *)object); You're adding trailing space here. More importantly though, the wined3d_desc variable is now essentially unused. I already mentioned on IRC a couple of weeks ago that I don't think changing the CreateBuffer() call like this is an improvement. I also mentioned that I think the patch is too big, I really don't want to fix regressions in this. The patch can be split in at least 4 separate patches without trying too hard.

March 30, 2009

Re: 16bit code generation

by David Laight

On Sun, Mar 29, 2009 at 06:23:53PM -0500, King InuYasha wrote: > > Unfortunately, at the moment it really is the best we have. AFAIK, there > isn't any other FOSS compiler that can build 16-bit DOS/Win16 applications. > Unless someone was actually willing to figure out how to make GCC be able to > target Win16 (not likely) or write a whole new compiler toolchain to target > Win16/DOS, there really isn't anything else left to use. Will 'Bruce's C Compiler' target DOS/Win 16 ? David -- David Laight: david(a)l8s.co.uk

March 30, 2009

SoC: JavaScript implementation

by Piotr Caban

Hi, I'm planning to participate in Google Summer of Code this year. I was thinking about working on recently added jscript.dll implementation. Its engine looks almost complete, but I can see that there are many unimplemented APIs. That's what I'd like to improve. I've already talked about this idea with Jacek, who has written jscript.dll, and he says that he likes it. I was looking for pages that intensively use JavaScript as well as simple real life test cases. My goals would be, in order: - Look at Wine jscript.dll related bugs. These would be: 15432, 15582, 16208, 16594 and 17152. I'm not sure if they are JScript or MSHTML bugs yet as they require deeper analyze. I will fix their JScript part of problem. - Fix W3School (http://www.w3schools.com/js/default.asp) JavaScript examples. These seem to be a nice tests for me. They test commonly used APIs in real life scenarios. I believe that if these tests work, most web sides should work as well. - Test complex web pages Pages like GMail or Google Office would be really cool to have working with our JavaScript. Unfortunately I'm afraid that it may be too much work for SoC to fix them. I'd like to do some testing and find some complex web pages that I could use as tests. If someone has any more ideas about tests I'm open for suggestions. For testing JavaScript on web pages I'm planning to use IE working on Wine with built-in jscript.dll. This way I will be able to test jscript.dll on web pages that is currently impossible to do with Wine MSHTML and iexplore.exe. What do you think about this idea? Thanks, Piotr Caban

March 30, 2009

Re: Advice on where to place new private methods and access to private methods across modules.

by Juan Lang

Hi Damian, > Is there an accepted approach for acessing support methods across the > modules? or should I just duplicate the necessary methods? Duplicating is the usually accepted approach. --Juan

March 30, 2009