Re: Support for IDvdInfo2::GetDiscID
On Sat, 19 Jun 2004 14:42:27 +0100 James Courtier-Dutton <[EMAIL PROTECTED]> wrote: > The Windows api method uses the function call IDvdInfo2::GetDiscID > http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c/directx/htm/idvdinfo2getdiscid.asp > > This returns a unique 64bit ID for a DVD. > Has anyone found out what exactly it does to create this 64bit ID. > It would be nice to get linux DVD players to be able to use the same method. If no-one else has figured it out yet, I might try my hand at reverse engineering it just for the hell of it. :P Tim
Re: [REGRESSION] Photoshop 7.0 works before wine-cvs-20040130 16:??:?? CST (bug #2017)
On Mon, 31 May 2004 17:53:58 +0200 Luca Capello <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello, > > as reported on bug #2017 [1], Adobe Photoshop 7.0 stops working after > wine-20031212 (in the majority of cases). This happens on Debian > unstable (where I am) as well as on other distro. As suggested by Tony > Lambregts, I made a regression testing to find the patch that broke this. A friend of mine who has a recent release of wine uses Photoshop 7 just fine. It was he and I who took the screenshot that's in the app database (we were using 2003-12-12 at the time). He just updated his wine install via gentoo's emerge about a week and a half ago. Tim
Re: Winelib and MFC and mixing native Windows DLLs
On Thu, 13 May 2004 09:37:04 -0700 Raghavan Gurumurthy <[EMAIL PROTECTED]> wrote: > I am trying to build my MFC-based Windows application on Linux. > > First question - I read in the Winelib user guide that I have to build MFC > completely on Winelib as well. Is this really a must? Is there no other alternative? I believe you'd have to build MFC on Winelib. > Second question - If my Windows application uses 10 DLLs, do I have to build all > these 10 DLLs in addition to the executable on Winelib? Or can I leave the 10 DLLs > run in 'native' mode and only convert the executable to be built with Winelib? You should be able to leave them in 'native' mode. Tim
Re: Load a .so from a Windows binary using Wine
On Wed, 12 May 2004 21:56:55 -0700 Raghavan Gurumurthy <[EMAIL PROTECTED]> wrote: > I have a Windows GUI application that runs on Wine (not Winelib). Now i want > to use that code to load a native Linux .so - how can i do this? Howso? I don't think wine has support for loading native shared libraries from windows apps. You'd have to write code to load the library (in the ELF format), map it into memory, etc. HTH, Tim
Re: Project David
On Sun, 9 May 2004 00:44:28 +0200 "Ge van Geldorp" <[EMAIL PROTECTED]> wrote: > There are some screenshots available now at > http://www.flexbeta.net/main/articles.php?action=show&id=56 One of the > comments on osnews noticed that in the picture > http://www.flexbeta.net/images/david/winbridge_install.gif the second > line in winbridge.lst is /etc/wine... There are more clues that this > project David is just a (possibly repackaged) Wine. You can also see "/usr/bin/wine-" in there as well. IMO it's rather ironic :P Tim
Re: SpecOpS David Exposed
On Tue, 27 Apr 2004 02:02:32 -0400 Abby Ricart <[EMAIL PROTECTED]> wrote: > I think I know what this David thing is all about! > > Please Read: > http://www.datiku.com/articles/david.php > Interesting theory. If that were true, then "David" could potentially be the most elaborate ripoff i've ever seen. "The next generation will, in effect, incorporate the operating system into the web browser, virtually eliminating the need for an operating system eventually, except to boot the computer and launch the browser." That would be a very scary thing. How in god's name could you incorporate an OS into a web browser, shouldn't it be the other way around? :P (well, they could have "david" running in Java, but that dosen't sound to feasable to me.) Assuming that they did have "david" in the kernel, and also assuming that they hold true to thier comments that david takes away the risk for "blue screens", as they had put it, then more than likely people'd be seeing a lot of white text on a red screen saying something along the lines of "David has caused a Page Fault (GPF) in module david.ko (0xdeadbeef). Please restart your computer." (i.e. Red Screen of Death [RSOD]) :P Tim
Re: Fwd: Re:SpecOpS Labs
On Mon, 26 Apr 2004 15:24:07 -0500 "R.U. Deranged" <[EMAIL PROTECTED]> wrote: > There's a story today on the results of the "unveiling" last week: > > http://www.inq7.net/inf/2004/apr/26/inf_4-1.htm > Interesting... A few things in that article don't seem right.. If the dude said that "David" was running the power point presentation, then why did he have to have his aide install it a second time (and install M$ Office a second time)? "Chua subsequently opened each Microsoft Office application, and showed that the "look-and-feel" of the applications remained intact, only this time it was running on a Linux box. By the time he ended the demo, the audience was applauding." Sounds like an easily moved audience. He could have simply been running Crossover Office, or Wine itself. I haven't tried installing Office under Wine, because I don't have a copy, but from what I've heard it's usable under Crossover Office. In thier autogenerated response email, they say that they intend to comply with the LGPL, so my biggest question is, when are they going to release thier supposedly LGPL'd code? :P I'd bet there is a lot of Wine code in there, otherwise why would they write: "[...] and we will comply with the GNU LESSER GENERAL PUBLIC LICENSE." I find it hillarious that they're making unfounded comments about Wine, yet more than likely at least 50%+ of thier code is Wine code, if there is any code at all. Tim
Re: Fwd: Re:SpecOpS Labs
I sent an inquiry and got the exact same response (twice), i believe it's a scripted response system. (In my case, it was "Good Evening, Mr. Hentenaar"). The claims they make about wine are just hillarious. :P I don't think they've ever even looked at the wine code, or else they'd know that thier claims are unfounded. :P Tim On Mon, 26 Apr 2004 18:59:34 +0200 "Ivan Leo Murray-Smith" <[EMAIL PROTECTED]> wrote: > I asked project davied if they know what use of LGPL code involves, and if > the're using wine code, I got the following answer. The impression I have is > that they are using major parts of wine. They claim they will fully comply with > the LGPL. Here is the full email they sent me. > > > Good Evening Mr. Smith > > > > > > Thanks for your email; We appreciate your taking the time to delve into > > Project David. We feel certain that the closer that you look at the project > > the more comfortable you will be with it. > > > > Our overall purpose of the project is to encourage consumers to use Linux. > > Our David Linux/Win Bridge software is simply a product to facilitate the > > transition to Linux. Our Linux/Win Bridge software is one of multiple > > components, which comprise our OS platform. In the future we will release > > another component, which is a set of tools that will encourage developers to > > write native Linux applications. > > > > The David software is a joint development effort between De La Salle > > University and SpecOpS Labs. Our Chief Technical Officer is Mr. Peter > > Valdez. As you may know Mr. Valdez is the founder of Tivoli Systems, which > > is now a multi billion-dollar flagship product of IBM. > > > > The code for our Windows/Linux Bridge is a hybrid of code, including our own > > proprietary code, and code from several open source projects. For now we > > are keeping the exact nature of our code under wraps until our first release > > of David. We are not using pirated or stolen code from Microsoft or any > > other source. As stated we are not disclosing the nature of our code or our > > exact methodology for running Windows Apps on Linux, this is for competitive > > and other reasons. However, a good deal of our success is attributed to our > > innovative methodology in assembling together open source code, proprietary > > code that we have written/purchased, and freeware. In the future, once we > > disclose how we have done this, then Im sure a number of developers will be > > kicking themselves in the rear end for not having thought of this > > themselves. > > > > We do encourage the open source movement and we will comply with the GNU > > LESSER GENERAL PUBLIC LICENSE. > > > > Our website is currently under construction, the data (*especially the > > technical data) on the website for the most part is not current and in some > > cases is up to 20+ months old. We are now in the process of doing a major > > overhaul of the site, which we expect to be completed in a few weeks. *The > > technical data on our web site concerning David, is outdated and in some > > cases a competitive smoke screen. We appreciate your comments on the WINE > > Project and we have no intention of misrepresenting the WINE. Therefore, we > > are now consulting our English-technical writers and the Filipino - > > designers/developers of David to ensure that there are no mistakes in the > > translation. Until we can update the website we have disabled the links to > > both our technical and competitive data. Hopefully, the development > > community wont get wrapped around the axle about David, and will withhold > > judgment until David is released. > > > > So far as our product goes we just completed our prototype, which has been > > in the making for quite some time. Our first release will be issued before > > the end of 2004; we expect to start Beta Testing in about 4-5 months. On 22 > > April we held a press conference at De La Salle University. During the press > > conference we demonstrated our prototype to more than 30 members of the > > local and international media. During the demo we ran Macromedia Flash, and > > MS Office on our Windows/Linux Bridge without a hitch. What you read in the > > media was primarily the result of the press conference/demo. David is not a > > hoax or vaporware, but we're not going to make any further claims about > > David at this point, We prefer to let our software do our talking for us. > > > > > > FYI: We are now a publicly traded company, our ticker symbol is SPLMF, you > > can view it on any major financial website such as Merrill Lynch: > > http://askmerrill.ml.com/markets_chart/1,2260,,00.html?q=SPLMF > > > > > > > > Thanks > > > > > > > > > > Customer Service > > SpecOpS Labs > > Summit One Office Tower > > Unit 23-H, 530 Shaw Blvd > > Mandaluyong City, Metro Manila, Philippines > > > > Office 63 2 532-7854 > > Fax63 2 532-5875 > > > > >
Re: project David?
On Fri, 23 Apr 2004 11:53:40 -0500 "R.U. Deranged" <[EMAIL PROTECTED]> wrote: > > The article states "David" is currently 80 MB. Anyone care to wager on how > much of that is Wine code? Their developers sure have been busy... > Yeah, I can almost predict that it will be at least 75% Wine code. I don't think they understand the LGPL, maybe someone should explain it to them, and how they're soon to be violating it. :P Tim
Re: project David?
On Thu, 22 Apr 2004 13:52:05 -0400 Kevin Koltzau <[EMAIL PROTECTED]> wrote: > And on > http://www.specopslabs.com/market_competition4.htm > They mention just taking all the previous > open source windows compatibility projects and > "incorporating the best features" of them all > > I wonder what that means exactly I wonder too... ya know, if they really cared, they'd be spending time trying to aid in projects such as wine, instead of trying to reinvent the wheel :P Tim
Re: DDraw issues, etc.
On Sun, 4 Apr 2004 10:58:44 +0200 Lionel Ulmer <[EMAIL PROTECTED]> wrote: > So you should just have to loop over all the rectangles and do the > 'copy_on_screen' as many times as there are rectangles. > > Of course, if they overlap, this method will still work except that we would > 're-Blit' some parts multiple times (we would just need to do the > optimisations later on). > Hmm... should this be implemented in DirectDrawSurface::Blt()? > Well, it's in my plans to do the GL 'port'... It could even be done pretty > easily (as almost all of the code already exists in the D3D part of the > code). It would be mightily hacky, but well, it may even work :-) > I'd say it'd be a bit faster than the current implementation, at least in most cases :P Sorry it took so long for me to reply, I've had a stroke of bad luck recently and had lost my will to code for a short time, and my will is back :) If there's anything I hate, it's losing my will to code, there isn't much else that's worse :P Tim
Re: DDraw issues, etc.
On Mon, 5 Apr 2004 02:20:51 +0200 (CEST) Francois Gouget <[EMAIL PROTECTED]> wrote: > It looks like an i810 to me (but I have never actually seen one so...) > > Do you know if it is integrated on the motherboard? And then is it an > Intel chipset? > > Also, cat /proc/asound/cards will tell you what type of sound card you > have. 0 [I82801BAICH2 ]: ICH - Intel 82801BA-ICH2 Intel 82801BA-ICH2 at 0x1200, irq 10 apparently it's an ICH2 and not an i810, and yes it is integrated on the motherboard. (My computer is a laptop :P) The odd thing about it is that the sound works fine in WineX (after a little hacking to get it to even run the app :/). Tim
Re: DDraw issues, etc.
On Sun, 4 Apr 2004 16:17:29 +0200 (CEST) Francois Gouget <[EMAIL PROTECTED]> wrote: > Do you have an i810 sound card by any chance? 00:1f.5 Multimedia audio controller: Intel Corp. 82801BA/BAM AC'97 Audio (rev 05) > I'm asking this because there are known problems with sound on i810 > soundcards, especially if you are using the Alsa drivers. I'm using the 2.6.0 kernel with the alsa kernel modules, and OSS emulation. > > It seems to be caused by a kernel bug which is triggered by the > full-duplex mode: > > http://crossover.codeweavers.com/pipermail/discuss/2003-December/005653.html > Hmm.. I don't believe that my card is an i810, it could be, but I have the alsa drivers statically linked into my kernel and I forgot exactly which one it is. Tim
Re: DDraw issues, etc.
On Sun, 4 Apr 2004 10:26:34 +0200 Lionel Ulmer <[EMAIL PROTECTED]> wrote: >Of course, if it uses more than one, some adaptations > would be needed :-/ And that it does :/ It seems not to update the screen properly, but then again, it could be something not completely implemented in Wine, or the game engine. > What do you mean by 'a destination rect that isn't present in the clip list' ? According to M$ DX7 Documentation, DirectDrawSurface::Blt() should only bit to areas that are in the clip list. And apparently 98% of the time that it's trying to blit to a rect that it's not putting in the clip list, it's almost identical to the RGNDATA.rcBound value, so i'm guessing it's for some type of back-buffer used by the engine :P > Oh well, it can be LOTS of stuff... In Windows, they have direct frame > buffer access so some games (like MI3) did a lot of updates of the screen > (which leads to a lots of traffic in Wine between game memory, X11 and the > frame buffer). It works perfectly well in Windows and will be slow as hell > in Wine. Yeah, that is unless the current DD code was rewritten to use GL and also assuming that the person running it had Direct Rendering, but then again, that would take a lot of time to do, and could possibly be horridly slow if the person happened not to have direct rendering :P I'm also looking at some of the wave driver stuff. WineX's wave driver (at least the OSS driver) does the sound for the game perfectly whereas Wine's wave output sounds rather odd, crackling, and it seems not to flush the buffer properly. :P Tim
Re: Microsoft SDK samples
On Sun, 04 Apr 2004 10:44:24 +0800 Jonathan Wilson <[EMAIL PROTECTED]> wrote: > Has anyone given thought to using the Microsoft SDK samples (e.g. DirectX > samples) to improve WINE? > i.e. take a particular sample and work away at it untill what you get in > WINE matches what you get in Windows. > > Although I suspect that there are things that the MS samples dont cover :) I've tried some of the DX samples that came with the DX7 SDK, and most of them seem to work, though it won't be *exactly* what you'd get in Win, it's close. Some of the samples may not work, but then again, I wouldn't trust M$ to write reliable code. :P Tim
Re: DDraw issues, etc.
On Sat, 3 Apr 2004 04:00:23 -0500 Tim Hentenaar <[EMAIL PROTECTED]> wrote: > > As far as I can see in the code, the > > only case supported with clipping is the case where only one rectangle is > > given in the clip list via the SetHWnd method (see, for example, > > User_copy_to_screen in dlls/ddraw/dsurface/user.c) which is the 'standard' > > case for windowed DirectX applications (like Media player) : a menu bar + a > > DirectX display zone. > > > I had a look, and implemented a clip list with one rect to use the same code as with an hWnd since they are virtually the same. This app is wierd in the fact that it dosen't use the hWnd for clipping with one rect, but rather a clip list with one rect. That fixed the drawing somewhat. > > Otherwise (ie multiple rectangles), you should check if you > > can support with the 'BitBlt' API something like the 'XSetClipRectangles' > > X11 API (which can't be called directly from DirectX anymore) which would > > prevent us rewriting in the DirectX code some generic 'multi-rectangle' > > clipping code. > I read through some of the M$ Docs, and it claims that DirectDrawSurface::Blt shouldn't be drawing to any area outside the destination surface's clip list if one exists. I accounted for this, and I'll say that the drawing looks a hell of a lot better, though the app has some now-obvious flaws that aren't apparent under native Winblows (at least when I tested it via VMWare), and in some places the drawing is quite slow. For instance, I noticed that the app sets the clip list, then tries to blit to a destination rect that isn't present in the clip list. I'm guessing that it's meaning to clip the source rect, but why you would clip the source surface is foreign to me. :P I'll have to dig a little deeper yet to figure this out. The main thing that irks me, is that even with clipping implemented, wherever it has to draw any sort of constant animation it's horribly slow (most of the time). Though when it plays a movie it plays perfectly. I'm guessing this would be a flaw in the game engine. I wrote an email to the company that made the game, asking for info, and haven't even gotten a responce :/ Tim
Re: DDraw issues, etc.
On Sat, 3 Apr 2004 10:26:12 +0200 Lionel Ulmer <[EMAIL PROTECTED]> wrote: > Usually, games use the Clipper to do 'non-full screen' DirectX applications. > There is no way to do a work-around to have it running in full-screen :-) ? While it doesn't make sense it does use the Clipper even in fullscreen mode. :P A little hacking, using FIXME() to reveal some info (I didn't want to enable TRACE() because it makes the app way too slow :P): fixme:ddraw:Main_DirectDrawClipper_SetClipList (0x47c9cfe0)->SetClipList(0x49d8cbe0,0) fixme:ddraw:Main_DirectDrawClipper_SetClipList - RGNDATA -- fixme:ddraw:Main_DirectDrawClipper_SetClipList dwSize: 32 fixme:ddraw:Main_DirectDrawClipper_SetClipList nCount: 3 fixme:ddraw:Main_DirectDrawClipper_SetClipList rcBound: 313,234,365,265 fixme:ddraw:Main_DirectDrawClipper_SetClipList fixme:ddraw:DIB_DirectDrawSurface_Blt (0x47c9bba8)->(0x406dfd34,0x46c4c640,0x406dfd24,0002,0x406dfc94) fixme:ddraw:DIB_DirectDrawSurface_Blt destrect :313x234-365x265 fixme:ddraw:DIB_DirectDrawSurface_Blt srcrect :313x234-365x265 fixme:ddraw:DIB_DirectDrawSurface_Blt flags: DDBLT_ROP > > Anyway, all this clipping is not really implemented properly as most of the > effort was spent on full screen apps. I might be up for fixing that, at least partially :P > As far as I can see in the code, the > only case supported with clipping is the case where only one rectangle is > given in the clip list via the SetHWnd method (see, for example, > User_copy_to_screen in dlls/ddraw/dsurface/user.c) which is the 'standard' > case for windowed DirectX applications (like Media player) : a menu bar + a > DirectX display zone. > I'll have a look at that. I did implement SetClipList/GetClipList even though I did it a bit hackishly IMO, it dosen't give any problems :P > Otherwise (ie multiple rectangles), you should check if you > can support with the 'BitBlt' API something like the 'XSetClipRectangles' > X11 API (which can't be called directly from DirectX anymore) which would > prevent us rewriting in the DirectX code some generic 'multi-rectangle' > clipping code. I'm guessing that the current DX implementation uses a user32-based rendering via BitBlit? I know that DX allows for HAL and User32-based drawing. I'll have a look at the XSetClipRectangles() man page and hope and pray that I can find a way to implement this :P Any further help you could give me would be appreciated. Thanks, Tim
DDraw issues, etc.
Hi all, I've implemented SetClipList and GetClipList in the DirectDraw Clipper, and I'm wondering how I should go about implementing clipping in DirectDraw's Blt() (if it isn't already done somewhere). M$'s documentation isn't too great, so I figured I should ask around. There's a game one of my relatives wants to run under Linux (it's a children's program), and the major problem is that it dosen't seem to handle clipping properly when blitting. (e.g. every time you move the mouse, it calls SetClipList). FYI, the binkw32.dll that came with the program was originally causing it to hang, but I patched the DLL and it works fine. If anyone else has had such problems, I could provide a patch. Also, I'm going to take a look at some of the DirectSound stuff too. The sound isn't very good quality for some reason, but under the WineX 3.3 CVS, sound works perfectly. Tim
