September 2005 - Wine-Devel

Re: WooHoo get a load of this :-)

by Kuba Ober

> Subject: $10,000 Open Challenge > SpecOpS Laboratories Here's my take from a technical point of view. I'd say that the only serious leap they might be able to make is to get some of the winserver into the Linux kernel and/or to use the freedce. There isn't really much more big stuff besides that to do in wine, architecturally I mean. Forgetting about the vxds for the moment, that is :) Otherwise, whatever they might claim as 'innovative' is really just the grunt work of implementing missing functionality in wine. And that can easily be done in an isolationist fashion, i.e. if they want to develop or reimplement some dlls, they just drop ones in wine (if any) and substitute with their own. They can also link wine dlls with some of their proprietary dlls that implement extra functionality, as long as they stay within LGPL. The only thing is that so far their PR campaign is all full of spin and hype, which might be just their cultural thing, or it might indicate that we're still talking vapourware. What's nice though is that I'm pretty sure that whatever they come up with will be reverse-engineered, analyzed and reimplemented back in wine, slowly but surely making their 'innovative product' redundant. Executive summary: down the drain the VC money goes. Cheers, Kuba

Sept. 21, 2005

Re: WooHoo get a load of this :-)

by Ivan Leo Puoti

Tom Wickline wrote: > 4. System becomes the property of SpecOpS Laboratories. Oh yeah, someone writes a full windows API implementation in a month or so, capable of replacing an OS that generates 1 billion US dollars a month in revenue, beating over a decade of open source wine development, and sells it to SpecOpS Laboratories for 10k, that's sure going to happen. I think anybody with the means to do that would make it open source, or sell it to the highest bidder. Ivan.

Sept. 21, 2005

WooHoo get a load of this :-)

by Tom Wickline

Fom : http://archives.free.net.ph/message/20050921.093916.4717740b.en.html $10,000 Open Challenge Top Page This message is part of the following thread: M the complete thread tree sorted by date Author: El Cid Ablang Date: To: linuxjobs Subject: $10,000 Open Challenge SpecOpS Laboratories $10,000 Open Challenge SpecOpS Laboratories (SpecOpS Labs) invites the Philippine ICT Community to participate in the DAVID Project. We are seeking a highly talented Consultant or Consulting Team that can contribute to the DAVID Project. SpecOpS Labs is searching the Philippines for Systems-Level Hacker/s to serve as Development Consultant to the DAVID Project. As proof or our sincerity, we are offering US$10,000.00* to the first Consultant or Consulting Team who can take our challenge and prove their capabilities. Our challenge requires the delivery of a solution that will allow an MS-XP compatible application to install and run under Linux using x.org and open source WINE by October 5, 2005. So, take the challenge now! Criteria to Award and Conditions: 1. System has no proprietary software imbedded / required. 2. System is stable. 3. MS-XP compatible modules / functions are working as expected. 4. System becomes the property of SpecOpS Laboratories. Registration Procedure: 1. Send us an Email indicating your intent to take up the challenge at <mailto:ablang@???> ablang@???. Attach your CV(s) or company profile (if applicable). 2. SpecOpS will Email you the Challenge Registration Form and further instructions. Challenge Activities: 1. Present the running solution at SpecOpS Labs office before October 5, 2005. 2. Validation of solution using SpecOpS Labs's criteria. 3. Award immediately. * All monies in this challenge are subject to tax. The decision of SpecOpS Labs for the award is final. ____________________________________________________ LinuxJobs Philippines (linuxjobs@???) Read the Guidelines: http://linux.org.ph/lists Searchable Archives: http://archives.free.net.ph This message was posted to the following mailing lists: LinuxJobs-PH Mailing List Info | Nearby Messages <- [ OT ] Journal subscription inquiry Community Mailing List Archives by the Free Network Group administrated by Federico Sevilla III Lurker (version 1.2)

Sept. 21, 2005

Re: Wine FAQ update #2

by Tom Wickline

On 9/21/05, Dimi Paun <dimi(a)lattica.com> wrote: > From: "Tom Wickline" <twickline(a)gmail.com> > >I forgot a </para> and put a trademark tag in for Bricscad, also fixed > >the Bricscad url. > > Can you please re-diff to the lastest and resend? Sure, i'll send it a little later today. Tom > > -- > Dimi Paun <dimi(a)lattica.com> > Lattica, Inc. >

Sept. 21, 2005

memory leak detection patch

by Mike McCormack

Hi, This patch is written for MSI, but could be adapted to other code. It keeps a linked list of allocated memory and removes free'd memory from the list. It requires that you change all the HeapAlloc's or mallocs in a dll to msi_alloc (for example), but can detect unfree'd memory and invalid free's. I have discovered quite a few problems in my own code with this patch, so hopefully somebody else will find it useful too. Mike

Sept. 21, 2005

Re: Wine FAQ update #2

by Dimi Paun

From: "Tom Wickline" <twickline(a)gmail.com> >I forgot a </para> and put a trademark tag in for Bricscad, also fixed >the Bricscad url. Can you please re-diff to the lastest and resend? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Sept. 21, 2005

Re: [Fwd: Re: [AppDB] new server supports GD2]

by Jeremy Newman

Glad it worked. Hopefully this will spur on more development on the AppDB and Bugzilla. The server had been humming very nicely on Debian since the move. The only glitch was with Mailman, which I'm still very sorry about. I wish mailman allowed me to put the date on the list view. You can customize the templates, but no additional variables (such as post date) are imported from the python scripts. On Wed, 2005-09-21 at 10:32 -0400, Chris Morgan wrote: > Screenshot regeneration just finished and they look much much better. Thanks > for the server upgrade Jeremy! > > Chris > > > On Wednesday 21 September 2005 5:43 am, Jonathan Ernst wrote: > > Check if it works on the live server after applying, then regenerate all > > screenshots from the admin. > > > > Thanks. > > > > > > Changelog: > > Use GD2 if it's available > > > > > > -------- Message transféré -------- > > De: Chris Morgan <cmorgan(a)alum.wpi.edu> > > À: Jonathan Ernst <Jonathan(a)ernstfamily.ch> > > Sujet: Re: [AppDB] new server supports GD2 > > Date: Sat, 17 Sep 2005 10:46:50 -0400 > > > > Very cool, I had no idea such a thing existed but that makes it a much > > nicer implementation for us I think. > > > > Chris > > > > On Saturday 17 September 2005 5:30 am, you wrote: > > > gd2 and gd1 use different functions, so that if php is compiled with gd2 > > > support, gd2 functions will be available: > > > > > > http://ch2.php.net/function_exists > > > > > > bye > > > > > > Le vendredi 16 septembre 2005 à 20:42 -0400, Chris Morgan a écrit : > > > > I'm not opposed to doing that, thats even one more step further than > > > > what I was proposing although I'm not sure how to do it. Does gd have > > > > some kind of version querying call we can use? > > > > > > > > Chris > > > > > > > > On Friday 16 September 2005 10:36 am, you wrote: > > > > > A better way would be to check for the availability of the functions. > > > > > (I recall a Wine discussion where Alexandre was telling someone to > > > > > check for bugs, not for versions to someone who wanted his > > > > > application to workaround some bugs in Wine; we should do the same > > > > > for AppDB IMO). > > > > > > > > > > What do you think ? > > > > > > > > > > I can't do it now, but if you don't do it in the next days, I'll have > > > > > a look at it. > > > > > > > > > > Le jeudi 15 septembre 2005 à 20:22 -0400, Chris Morgan a écrit : > > > > > > Can we use a define at the top of the file that specifies GD1 or > > > > > > GD2 so we don't have to comment one set out and uncomment the other > > > > > > if we or anyone else has to switch? > > > > > > > > > > > > Chris > > > > > > > > > > > > On Thursday 15 September 2005 5:01 am, Jonathan Ernst wrote: > > > > > > > Hi Chris, > > > > > > > > > > > > > > Something wrong with this one ? > > > > > > > > > > > > > > Le mercredi 31 août 2005 à 15:16 +0200, Jonathan Ernst a écrit : > > > > > > > > To be applied after Jeremy confirms that GD2 is installed. > > > > > > > > To test: go to the admin and regenerate all pictures > > > > > > > > > > > > > > > > Changelog: > > > > > > > > - use GD2 php functions to get nicer screenshots

Sept. 21, 2005

Re: [Fwd: Re: [AppDB] new server supports GD2]

by Chris Morgan

Screenshot regeneration just finished and they look much much better. Thanks for the server upgrade Jeremy! Chris On Wednesday 21 September 2005 5:43 am, Jonathan Ernst wrote: > Check if it works on the live server after applying, then regenerate all > screenshots from the admin. > > Thanks. > > > Changelog: > Use GD2 if it's available > > > -------- Message transféré -------- > De: Chris Morgan <cmorgan(a)alum.wpi.edu> > À: Jonathan Ernst <Jonathan(a)ernstfamily.ch> > Sujet: Re: [AppDB] new server supports GD2 > Date: Sat, 17 Sep 2005 10:46:50 -0400 > > Very cool, I had no idea such a thing existed but that makes it a much > nicer implementation for us I think. > > Chris > > On Saturday 17 September 2005 5:30 am, you wrote: > > gd2 and gd1 use different functions, so that if php is compiled with gd2 > > support, gd2 functions will be available: > > > > http://ch2.php.net/function_exists > > > > bye > > > > Le vendredi 16 septembre 2005 à 20:42 -0400, Chris Morgan a écrit : > > > I'm not opposed to doing that, thats even one more step further than > > > what I was proposing although I'm not sure how to do it. Does gd have > > > some kind of version querying call we can use? > > > > > > Chris > > > > > > On Friday 16 September 2005 10:36 am, you wrote: > > > > A better way would be to check for the availability of the functions. > > > > (I recall a Wine discussion where Alexandre was telling someone to > > > > check for bugs, not for versions to someone who wanted his > > > > application to workaround some bugs in Wine; we should do the same > > > > for AppDB IMO). > > > > > > > > What do you think ? > > > > > > > > I can't do it now, but if you don't do it in the next days, I'll have > > > > a look at it. > > > > > > > > Le jeudi 15 septembre 2005 à 20:22 -0400, Chris Morgan a écrit : > > > > > Can we use a define at the top of the file that specifies GD1 or > > > > > GD2 so we don't have to comment one set out and uncomment the other > > > > > if we or anyone else has to switch? > > > > > > > > > > Chris > > > > > > > > > > On Thursday 15 September 2005 5:01 am, Jonathan Ernst wrote: > > > > > > Hi Chris, > > > > > > > > > > > > Something wrong with this one ? > > > > > > > > > > > > Le mercredi 31 août 2005 à 15:16 +0200, Jonathan Ernst a écrit : > > > > > > > To be applied after Jeremy confirms that GD2 is installed. > > > > > > > To test: go to the admin and regenerate all pictures > > > > > > > > > > > > > > Changelog: > > > > > > > - use GD2 php functions to get nicer screenshots

Sept. 21, 2005

Re: D3D7 -> WineD3D

by Oliver Stieber

--- Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > * Not a problem, but a suggestion: Does it make sense to have DirectDraw using > WineD3D? Without direct access to the video memory it's slow, and DGA has > permission problems. Using WineD3D here might make surfaces less trouble, and > it could give better performance without needing rw access to /dev/mem. > p.s. the reason for intergrating with ddraw is so that X11Drv works properly with wined3d, this affects things like locking the mouse to a window in full screen mode and being able to Get and Release the DC for the surface. > > http://www.winehq.org/pipermail/wine-patches/2005-September/020829.html > I've seen it, but I've spent all my time hacking on D3D7->WineD3D > Great.. Oliver > Stefan > > > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Sept. 21, 2005

Re: D3D7 -> WineD3D

by Oliver Stieber

--- Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hello, > > It's almost ready for DirectX 8 but there quite a bit of work intergrating > > things with ddraw surfaces before DirectX 7 can be moved over. > I decided to give it a try without thinking for a long time, and I've made > little progress: I've replaced the old OpenGL interface with a stub which is > ready to take calls to WineD3D. I've noticed the following problems so far: > > * Headers: WineD3D depends on the d3d8 or d3d9 headers. I've made the check > pass with d3d.h, but I had to copy a lot of definitions from d3d9types.h. The > thing compiles without errors or warnings now, but there may be side effects > I don't know for now. > Where there is a difference between d3d8 and d3d9 headers a new type is created WINED3DFOOBAR and put into include/wine/wined3dtypes.h, this should be easy enough to extend to d3d7. > * Surfaces... You mentioned it, I think I don't need to explain anything > here ;-) > > * Not a problem, but a suggestion: Does it make sense to have DirectDraw using > WineD3D? Without direct access to the video memory it's slow, and DGA has > permission problems. Using WineD3D here might make surfaces less trouble, and > it could give better performance without needing rw access to /dev/mem. That's defiantly a possibility but we'd still need to support people who don't have accelerated OpenGL graphics. I think getting the DIB engine merge would be more beneficial. > > > http://www.winehq.org/pipermail/wine-patches/2005-September/020829.html > I've seen it, but I've spent all my time hacking on D3D7->WineD3D > > Stefan > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Sept. 21, 2005

D3D7 -> WineD3D

by Stefan Dösinger

Hello, > It's almost ready for DirectX 8 but there quite a bit of work intergrating > things with ddraw surfaces before DirectX 7 can be moved over. I decided to give it a try without thinking for a long time, and I've made little progress: I've replaced the old OpenGL interface with a stub which is ready to take calls to WineD3D. I've noticed the following problems so far: * Headers: WineD3D depends on the d3d8 or d3d9 headers. I've made the check pass with d3d.h, but I had to copy a lot of definitions from d3d9types.h. The thing compiles without errors or warnings now, but there may be side effects I don't know for now. * Surfaces... You mentioned it, I think I don't need to explain anything here ;-) * Not a problem, but a suggestion: Does it make sense to have DirectDraw using WineD3D? Without direct access to the video memory it's slow, and DGA has permission problems. Using WineD3D here might make surfaces less trouble, and it could give better performance without needing rw access to /dev/mem. > http://www.winehq.org/pipermail/wine-patches/2005-September/020829.html I've seen it, but I've spent all my time hacking on D3D7->WineD3D Stefan

Sept. 21, 2005

Googletalk unable to connect

by Vijay Kiran Kamuju

Hi, I think i might have found one missing link why one cannot connect using gmal. When i was looking through symbols in googletalk.exe, i have found that there are strings like WinHttp* These are functions in winhttp.dll, defined in winhttp.h I will send you details if i find any other thing. bye, Vijay

Sept. 21, 2005

Re: Documentation volunteer(s) needed

by Oliver Stieber

--- Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hello, > > > I'm just about to put it into wined3d, I can have a look at backporting it > > to d3d7 but the idea is to get d3d7 using wined3d at some point. > That would be certainly interesting. Is wined3d ready for this yet? It would > make much more sense to change this now instead of looking for bugs in D3D7 > when we know it will be removed in the not-so-far future. > It's almost ready for DirectX 8 but there quite a bit of work intergrating things with ddraw surfaces before DirectX 7 can be moved over. > > All you have to do is flag the backbuffer when it's cleared as cleared, and > > then at the end of a drawing function flag the backbuffer as not cleared. > > Then when you lock the backbuffer check the flag and if it's flagged as > > cleared just memset the buffer to whatever the clear value is instead of > > doing a glReadPixels (most of the time you don't need the memset because > > the buffer is going to be completely rewritten, on my home pc without the > > hack I get about 10fps max with 100% CPU load, with the hack I get 30fps > > with about 30% CPU load) > I'll look at this. Thanks > http://www.winehq.org/pipermail/wine-patches/2005-September/020829.html > > Hmm.. I haven't had any problems with that yet, so long as I'm actually > > using GL_TEXTURE_2D and providing texture coordinates, in wined3d I > > disable any texture states that aren't used: > Sounds interesting. I'll have a look. > > Stefan > ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

Sept. 21, 2005

Re: freedce/win32 - making progress.

by Luke Kenneth Casson Leighton

hello peter, thank you v. much for the advice. yes i tried -no-undefined, it got a little further but no banana :) will look at that patch, let you know if it helps On Wed, Sep 21, 2005 at 01:44:12PM +0200, Peter Ekberg wrote: > Hi! > > * Luke Kenneth Casson Leighton writes: > > okay, i'm getting somewhere, and there's a key part that i would > > appreciate some advice about: if there is anyone who knows how to > > do cross-compiling of dlls using libtool, mingw32 (in automake > > Makefile.am's) where the dlls need to link against _other_ libraries, > > i would love to hear from you. > > > > if you know of a better place to ask questions such as these, i would > > also appreciate some advice on where i should ask them. > > Perhaps libtool(a)gnu.org, but please be more detailed in what > you're trying to do and what you want to happen. > > > [please respond cc direct because although i am subscribed > > to the wine-devel list i have "receive postings" switched off > > because i haven't sufficient time any more to sort or delete > > hundreds of messages per day like i used to have. > > ] > > > > there are about eight libraries containing a function > > rpc__module_init_func() and these need to be LoadLibrary'd and > > GetProcAddress'd and called... > > > > ... but in endeavouring to create dlls, i am getting mad warnings from > > libtool about a) static libraries containing unresolved functions > > therefore libtool says it _could_ link against the library you > > requested, but only if you made a dynamic version and b) unresolved > > symbols for functions in other libraries, and it's all a bit of > > a vicious circle and i'd rather not bash my head against a brick > > wall for days on this. > > You could try the first patch in this post: > http://lists.gnu.org/archive/html/libtool/2005-09/msg00063.html > > It just might help... > > It could also be that it's as simple as saying -no-undefined > to libtool, that option is needed on windows. > > But as always it's hard to tell without all the gory details. > > > if this issue cannot be resolved then there are a number of nasty > > options remaining: > > > > 1) statically link binaries against the libraries, with hard-coded > > module init functions (which is what i'm doing now and i link against > > libnaf_ip.la, libcom.la, libprot_ncacn.la, libprot_ncadg.la, the list > > goes on and you have to do that for EVERY client AND server program) > > > > 2) abandon automake, work out how to manually create dlls. yes i know > > about .def files but libtool appears unconvinced. > > > > neither of these two is attractive options. > > > > anyway: what i have working so far can be found at the freedce-devel > > sf.net mailing list archives, and as of today, rpcd (the endpoint > mapper > > on port 135) works. > > > > and also when i add a NamedPipes transport (ncacn_np) it will > > be on \PIPE\epmapper, too. that'll be a fun job. no, really! > > > > tomorrow's job is to link the echo_server and test that, and if that > > works, try the echo_client too. > > > > if those work, then the free software community will have its own > > DCE/RPC reference implementation running on win32. > > > > much damn good may it do, i am sure. > > > > l. > > > > p.s. thank goodness for pthreads-win32. > > > > Cheers, > Peter -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

Sept. 21, 2005

RE: freedce/win32 - making progress.

by Peter Ekberg

Hi! * Luke Kenneth Casson Leighton writes: > okay, i'm getting somewhere, and there's a key part that i would > appreciate some advice about: if there is anyone who knows how to > do cross-compiling of dlls using libtool, mingw32 (in automake > Makefile.am's) where the dlls need to link against _other_ libraries, > i would love to hear from you. > > if you know of a better place to ask questions such as these, i would > also appreciate some advice on where i should ask them. Perhaps libtool(a)gnu.org, but please be more detailed in what you're trying to do and what you want to happen. > [please respond cc direct because although i am subscribed > to the wine-devel list i have "receive postings" switched off > because i haven't sufficient time any more to sort or delete > hundreds of messages per day like i used to have. > ] > > there are about eight libraries containing a function > rpc__module_init_func() and these need to be LoadLibrary'd and > GetProcAddress'd and called... > > ... but in endeavouring to create dlls, i am getting mad warnings from > libtool about a) static libraries containing unresolved functions > therefore libtool says it _could_ link against the library you > requested, but only if you made a dynamic version and b) unresolved > symbols for functions in other libraries, and it's all a bit of > a vicious circle and i'd rather not bash my head against a brick > wall for days on this. You could try the first patch in this post: http://lists.gnu.org/archive/html/libtool/2005-09/msg00063.html It just might help... It could also be that it's as simple as saying -no-undefined to libtool, that option is needed on windows. But as always it's hard to tell without all the gory details. > if this issue cannot be resolved then there are a number of nasty > options remaining: > > 1) statically link binaries against the libraries, with hard-coded > module init functions (which is what i'm doing now and i link against > libnaf_ip.la, libcom.la, libprot_ncacn.la, libprot_ncadg.la, the list > goes on and you have to do that for EVERY client AND server program) > > 2) abandon automake, work out how to manually create dlls. yes i know > about .def files but libtool appears unconvinced. > > neither of these two is attractive options. > > anyway: what i have working so far can be found at the freedce-devel > sf.net mailing list archives, and as of today, rpcd (the endpoint mapper > on port 135) works. > > and also when i add a NamedPipes transport (ncacn_np) it will > be on \PIPE\epmapper, too. that'll be a fun job. no, really! > > tomorrow's job is to link the echo_server and test that, and if that > works, try the echo_client too. > > if those work, then the free software community will have its own > DCE/RPC reference implementation running on win32. > > much damn good may it do, i am sure. > > l. > > p.s. thank goodness for pthreads-win32. > Cheers, Peter

Sept. 21, 2005

Re: riched versions

by Andreas Mohr

Hi, On Mon, Sep 19, 2005 at 06:04:16PM +0200, wino(a)piments.com wrote: > trying to get recent (winecfg) wine versions to run a program and it shows > an error saying riched20.dll version <unspecified> is found and it > "requires" 5.2...... > > I would have thought that the build-in is probably fine , it is just a > version check that is failing. Is there a way to con it or is the only way > to pull in a versioned native dll? Send me WINEDEBUG=+relay program.exe &>/tmp/riched20.log; bzip2 /tmp/riched20.log and I'll try to figure out what we're missing... Andreas Mohr

Sept. 21, 2005

Finding apps that are keeping organizations from switching to Linux

by dank＠kegel.com

I've been thinking about how to boost Wine adoption among organizations that are considering migrating their desktops from Windows to Linux. It seems like the place Wine could have the most impact is at sites which have just one crucial Windows app which is keeping them from migrating So I'm thinking about compiling a list of these keystone apps, starting a little informal QA of Wine using them, and filing reproducible bugs in the winehq bugzilla. Does anyone have suggestions for apps to consider for that list? I'm looking for semispecialized apps that haven't gotten much attention from Wine to date, and that have free demo versions or have vendors willing to provide copies of their Windows apps for QA under Wine. I'll probably focus on one to three such apps, since my time's pretty limited. For example, I ran into such an app while volunteering at a 500-member church. Just about the time I was starting to think about moving them to Linux, they bought a package called "Church Windows", and quickly became completely dependent upon it. There are probably three or so apps in the "church management" category that, if supported by Wine, would enable thousands of churches to consider migrating to Linux. Perhaps some of you who have worked at churches/schools/nonprofits/companies can chime in here... Thanks, Dan Related links for church management software: http://www.winehq.com/hypermail/wine-devel/2003/09/0617.html http://www.rmcumc.org/CR/computer/ http://www.united-church.ca/it/software/ http://associate.com/camsoc/crs/ http://www.capterra.com/church-management-software http://www.neumc.org/page.asp?TableName=oPages_6KF3UU&PKValue=82 http://www.linuxjournal.com/article/7653

Sept. 21, 2005

Re: XEmbed Systray Support

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > + ev.xclient.type = ClientMessage; > + ev.xclient.window = systray_window; > + ev.xclient.message_type = x11drv_atom(_NET_SYSTEM_TRAY_OPCODE); > + ev.xclient.format = 32; > + ev.xclient.data.l[0] = CurrentTime; > + ev.xclient.data.l[1] = SYSTEM_TRAY_REQUEST_DOCK; > + ev.xclient.data.l[2] = data->whole_window; > + XSendEvent( display, systray_window, False, NoEventMask, &ev ); > + XSync( display, False ); You need to get the tsx11 lock when calling X functions. Also what's the reason for having an XSync here? -- Alexandre Julliard julliard(a)winehq.org

Sept. 21, 2005

Re: Windows CE on Wine

by Boaz Harrosh

On 9/20/05, Filip Navara <navaraf(a)reactos.com> wrote: >>It was proved that to run simple WinCE/x86 programs all that is >>needed is to get the loader to accept the WinCE PE signature (which Wine >>used to ignore and probably still does) and have implementation of the >>DLLs... >> >> Was that on React-OS or on Wine? Steven Edwards wrote: > >I had to flip the subsystem ID of a WinCE test app using one of the >msvc build tools. My sample application just called a message box api. >I don't know if any more complex WinCE applications would work due to >threading and memory management differences. > > OK Exactly! At first I did not think we could use the same binaries. Just maybe the same codebase but compiled with different set of makefiles. I'm not even sure the ABI is the same. The sameness is only promised at the source code API level. Funny how Microsoft uses a totally different set of Headers for CE. Even the Wine-headers are closer to the original SDK than CE. The order of function is different, the macros, the styling. There is no resemblance, not even one name of one parameter. Just the Function name and the Header name. Its like they had a copyright problem and needed to write it from scratch.:) Now for wine I will not do the same. I'll try to keep the same headers, and where there are ABI differences. Like calling convention parameter sizes.. I'll try to use a macro. On the implementation side Linux is Linux is Linux so I guess that should work well. But it looks like The Win32 API was shifted around a bit so in CE functions don't sit in the same Dll's as they sit in Win32, and apps are linked differently. So spec files and Makefiles will have to be different. What I'm afraid of is the things I don't know, which is how x86 is Wine. And how separated is that from the rest of the code. Thanks guys Boaz

Sept. 21, 2005

Re: listview: infoPtr might be invalid after WM_NOTIFY

by Phil Krylov

On Tue, 20 Sep 2005 16:20:50 -0500 Robert Shearman <rob(a)codeweavers.com> wrote: > Since this was a behaviour in our file open dialog, did we even verify > that this was a listview bug or is it that destroying the listview in > the middle of a notification is something that you shouldn't do? The native file dialog acts the same way. -- Ph.

Sept. 21, 2005

Edit XML/SGML files the easy way :-)

by Tom Wickline

Hello, If anyone is looking for a nice tool to edit XML/SGML files epcEdit is the way to go.. It runs on Linux, Windows, Solaris, & Wine And it comes with a sixty day free evaluation. http://www.epcedit.com/ Tom

Sept. 21, 2005

Re: Documentation volunteer(s) needed

by Stefan Dösinger

Hello, > I'm just about to put it into wined3d, I can have a look at backporting it > to d3d7 but the idea is to get d3d7 using wined3d at some point. That would be certainly interesting. Is wined3d ready for this yet? It would make much more sense to change this now instead of looking for bugs in D3D7 when we know it will be removed in the not-so-far future. > All you have to do is flag the backbuffer when it's cleared as cleared, and > then at the end of a drawing function flag the backbuffer as not cleared. > Then when you lock the backbuffer check the flag and if it's flagged as > cleared just memset the buffer to whatever the clear value is instead of > doing a glReadPixels (most of the time you don't need the memset because > the buffer is going to be completely rewritten, on my home pc without the > hack I get about 10fps max with 100% CPU load, with the hack I get 30fps > with about 30% CPU load) I'll look at this. Thanks > Hmm.. I haven't had any problems with that yet, so long as I'm actually > using GL_TEXTURE_2D and providing texture coordinates, in wined3d I > disable any texture states that aren't used: Sounds interesting. I'll have a look. Stefan

Sept. 21, 2005

Re: IDE disk geometry

by Uwe Bonnes

>>>>> "Michael" == Michael Ost <most(a)museresearch.com> writes: Michael> On Tue, 2005-09-20 at 18:22, Vitaliy Margolen wrote: >> Tuesday, September 20, 2005, 6:11:49 PM, Michael Ost wrote: > Should >> I put my code in CDROM_DeviceIoControl? Or handle it in > >> NtDeviceIoControlFile? Should I pass all other IoControlCodes except >> > IOCTL_DISK_DRIVE_GET_GEOMETRY for a verifiable IDE drive on to the >> > CDROM_... function? I don't it make any sense to create the whole >> new file to parse just one IOCTL. So you might just add it to the >> cdrom.c I think that might get accepted. Michael> I don't think it was clear that the device in question is not a Michael> CDROM, but a hard disk. Are IDE hard disks supposed to be Michael> lumped in with CDROMs in the code? Our IOCTL handling is a mess. I had a patch that splitted out IOCTL code handling to separate, loadable dlls, but the patch went by unnoticed. Look for Mail from around July 10 "Uniform SYS/VXD Handling x/6" In your case, when you did CreateFile("\\c:\"), in file.c it would be noticed that a raw handle on the disk is needed and something like "disk.sys" would be loaded, where you would implement the needed IOCTL. ... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Sept. 21, 2005

Re: Windows CE on Wine

by Andreas Mohr

Hi, On Wed, Sep 21, 2005 at 10:35:13AM +0200, Boaz Harrosh wrote: > Funny how Microsoft uses a totally different set of Headers for CE. > Even the Wine-headers are closer to the original SDK than CE. The order > of function is different, the macros, the styling. There is no > resemblance, not even one name of one parameter. Just the Function name > and the Header name. Its like they had a copyright problem and needed to > write it from scratch.:) Just an outrageously wild guess: OS/2? Maybe the standard Windows headers were going back to the time where they cooperated with IBM to create OS/2, so they decided to play it safe and create a completely new header set that they would be able to reuse for their main Windows tree in case IBM were to sue them in the very distant future? The same goes for the actual CE source code, I guess... > What I'm afraid of is the things I don't know, which is how x86 is Wine. > And how separated is that from the rest of the code. You will probably have an exciting job ahead of you, good luck! ;) Andreas Mohr

Sept. 21, 2005

RE: IDE disk geometry

by Ge van Geldorp

> From: Vitaliy Margolen > > So all you need to do > is to find where this information is stored on windows (it > has to be somewhere in registry It's an IOCTL, so it is passed to the disk driver on Windows. Although it is possible that the driver caches the info in the registry, I don't think that's very likely (and it would be driver-dependent). That doesn't mean that Wine can't store the info where it pleases (e.g. in the registry). Ge van Geldorp.

Sept. 21, 2005