June 2003 - Wine-Devel - list.winehq.org

Re: Add root drive mapping to default config file

by Mike Hearn

Oooh, here's an idea - how about if when you ran wine from an area of disk that wouldn't normally be mapped, it creates a temporary "ghost" mapping that doesn't appear in the config file but only for itself and child processes? It takes precedance... That way you wouldn't have to keep either moving files around or mapping new drives. Thoughts? On Tue, 2003-06-03 at 10:22, mike(a)theoretic.com wrote: > > - its insecure, since you can write everywhere you want > > and some filesystem corruption still exist today. > > Only if you run Wine as root. What makes us think we trust Linux software > more than Win32 software? > > > - it will cause recursion/drive change problems => > > example : what will be the current drive/directory > > if you access the fake C:\windows > > via Z:\home\user\fake_c\windows ? > > Good question. I guess the algorithm must be able to deal with that > though, as I've been running with / mapped for months and it hasn't caused > any problems that I can see. Simply chopping out subtrees if they are > mapped elsewhere would work. > > > On my RH box I have a drive called W: that contains wine sources and P: > > contains programs/. > > If I am in W: (wcmd) and I do 'cd programs', wcmd now says P:\. > > Yes, that might be a bit confusing (if you use wcmd), but for newbies > having the "Wine cannot find executable" error is even more confusing. > > Well, I'm not really bothered either way, but something would need to be > done to address those problems I think. > > -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

June 3, 2003

Re: Add root drive mapping to default config file

by mike＠theoretic.com

> - its insecure, since you can write everywhere you want > and some filesystem corruption still exist today. Only if you run Wine as root. What makes us think we trust Linux software more than Win32 software? > - it will cause recursion/drive change problems => > example : what will be the current drive/directory > if you access the fake C:\windows > via Z:\home\user\fake_c\windows ? Good question. I guess the algorithm must be able to deal with that though, as I've been running with / mapped for months and it hasn't caused any problems that I can see. Simply chopping out subtrees if they are mapped elsewhere would work. > On my RH box I have a drive called W: that contains wine sources and P: > contains programs/. > If I am in W: (wcmd) and I do 'cd programs', wcmd now says P:\. Yes, that might be a bit confusing (if you use wcmd), but for newbies having the "Wine cannot find executable" error is even more confusing. Well, I'm not really bothered either way, but something would need to be done to address those problems I think.

June 3, 2003

Re: Status page update #1

by MichaelGuennewig＠gmx.de

Tom <twickline(a)skybest.com> writes: > Hello, > > I am working on another Status page update and here > is a list of Component's that currently dont have a primary > worker asighned. If you are a worker on any of these Component's > can you let me know and I will add you in as the worker. > > Also if you are aware of a Status % work done on any of these > can you let me know. old status: ----------- msvfw32: Video for Windows (VFW) "No Codec implemented" new status: ----------- msvfw32: Video for Windows (VFW) msrle32: "MS-RLE vide codec" (Recent primary workers: Michael Günnewig) decompression works, 8-bit compression works, 4-bit will come avifile/avifil32: "AVI file handler" (Recent primary workers: Michael Günnewig) interface de/compressing audio: complete. interface compressing video : complete. interface decompressing video : complete. interface for WAV files: Wave complete, Sun Audio still missing. interface for AVI files: loading works. creating from scratch works. saving still missing. API and interface for editing: missing API for loading, creation, information: complete API for saving, clipboard: missing Michael

June 3, 2003

Re: Documentation?

by Mike Hearn

> On the Wine Status DLL page comctl32 is reported > of having nonexistant documentaion. A quick look in > the CVS browser-thingy shows that in the code itself, > comctl32 is quite nicely documented. So what exactly > is needed? A good question. I've been wondering that myself. For comctl32, the documentation is all provided by MSDN. I recall reading somebody say a while back that to be a completely independant Win32 implementation the project would need to have MSDN style documentation as well, but as the docs are freely available I can't see anybody having serious motivation to do that anytime soon. I think really the biggest need for documentation is on the internals of how Wine works, for instance how and why Wine overrides pthreads, but unfortunately some of that stuff is Jedi-level code - I'm not sure it could be easily documented by somebody who didn't write it. Anybody else? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

June 3, 2003

Documentation?

by Hal Mikimoto

Hello all, I've been watching Wine grow for the last two years or somsuch. During this time I have wished that I could contribute to the cause, but alas my coding skills rank somewhere around the level of Jello and can't offer much there. While reading the list I saw the Wine Status pages were linked a few emails ago. I have never seen these pages before and a quick glance and shown that the Documentation side of things needs some TLC *badly*. For those who don't know who I am, I wrote a PSX internals doc a few years ago that made Slashdot a few times. I quite versed at internet data mining and putting the resultant finds in documentation form. The problem is that I'm confused by what kind of documentation you need. Let me give you an example. On the Wine Status DLL page comctl32 is reported of having nonexistant documentaion. A quick look in the CVS browser-thingy shows that in the code itself, comctl32 is quite nicely documented. So what exactly is needed? An API listing? a very verbose version of the .spec file? How to use it? What it does? It's depencies? Is there a particular format I have to stick to? Could anyone hive a pointer of what exactly you are looking for? Joshua "Haruhito" Walker P.S. I have a killer Registry API book too, if that helps any. __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com

June 3, 2003

Re: Add root drive mapping to default config file

by PETREOLLE Sylvain

Hi Mike, please dont add / to the default config. Some reasons no to do that: - its insecure, since you can write everywhere you want and some filesystem corruption still exist today. - it will cause recursion/drive change problems => example : what will be the current drive/directory if you access the fake C:\windows via Z:\home\user\fake_c\windows ? On my RH box I have a drive called W: that contains wine sources and P: contains programs/. If I am in W: (wcmd) and I do 'cd programs', wcmd now says P:\. Sylvain Petreolle -at work-

June 3, 2003

Re: Merge of WineX's (LGPL licensed) wininet.dll code

by Robert Shearman

> Subject: Re: Merge of WineX's (LGPL licensed) wininet.dll code > From: Mike Hearn <m.hearn(a)signal.qinetiq.com> > To: wine-devel(a)winehq.org > Cc: wine-patches <wine-patches(a)winehq.com>, david(a)transgaming.com > Organization: QinetiQ - Malvern Technology Center > Date: 02 Jun 2003 14:32:42 +0100 > Just thought I'd let people know (while we're on the WinInet topic) that I'm working on the UrlCache functions there, leading to implementing the UrlMon functions properly. Rob

June 2, 2003

Re: Merge of WineX's (LGPL licensed) wininet.dll code

by David Hammerton

Hi There, This would be related to the open-ssl thing I did... Basically rather than rewriting a bunch of wininet code, I wrote a layer around the winsock stuff so that it can easily switch between ssl and non-ssl sockets.. The odd thing is in my WineX tree (where I do my development) that fixme isn't in InternetReadFile - theres now only one, and thats in InterneWriteFile... Mike McCormack - is it possible this file (internet.c) didn't get merged properly? Mike Hearn - check out the function 'InternetReadFile' at this URL and compare against your post-patched winehq version. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/winex/wine/dlls/wininet/inte… *few minutes later* ok, so I checked out winehq cvs and applied the patch.. Mike McCormack - it looks like you merged the contents of InternetWriteFile into both InternetWriteFile and InternetReadFile.. I may be wrong (I just woke up).. The FIXME in InternetWriteFile has no bad effect, things will still work (so long as you're not using HTTPS) - but in InternetReadFile, I have my doubts. Cheers. David On Mon, 2 Jun 2003 23:32, Mike Hearn wrote: > Well, I'm spending my fun afternoon trying to get IE to install in Wine > (it breaks in a new and interesting way every time I try this). > > Before the patch, it didn't work, couldn't contact download sites. After > the patch, it still doesn't work, and I get this fixme: > > fixme:wininet:InternetReadFile This shouldn't be here! We don't support > this kind of connection anymore. Must use NETCON functions, especially > if using SSL > > Which seems a bit of a bummer, if IE6 setup needs that type of > connection I think we should still support it really...... > > I think the problem might be lack of proxy workingness. Am investigating > now. Would be nice to lift proxy details from the http_proxy variable in > future.... > > One last thing, the patch seemed to have a lot of whitespace no-ops, > running diff with -bB should eliminate some. > > thanks -mike -- David Hammerton TransGaming Technologies david(a)transgaming.com http://www.transgaming.com/ *Let the games begin*

June 2, 2003

Re: [D3D] Some execute buffers rewrites + misc fixes

by Lionel Ulmer

> This seems like the Copy/Paste syndrom [:-)] Anyway, I fixed it in one of my pending patch. > Yes! From a ZBuffer surface to another... Don't remember the game > though... (because it crashed in another part of wine) Wow... This is nice :-) > When doing the standard blit, the app set the DDBLT struct pointer to > NULL so > without the check this simply crashes when accessing the depthfill > member of the structure. Yeah, it's in my plans to have the ZBuffer a bit better handled to not crash when applications do strange things with it... Proper Lock / Blt support will never be fast on any GL implementation I know though :-/ > Yes this can be done as well. [:-)] Fixed it in one of my patches too. > Because the world transformation introduced the W coordinate which > cannot be passed > to drawing functions. But well, this coordinate should be always be 1 > after the world transformation so we can ommit it. Well, you can pass the W coordinates using the 1/W trick, no ? If you use the XYZRHW format and give it X, Y, Z, 1/W after your computation it should work, no ? Slow but working from what I can see... > Oh! Well I forgot this hack... [;-)] I think to support this using GL, we should use the feedback buffer. Will surely be slow, but well, better than to write our own lighting :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

June 2, 2003

Re: [D3D] Some execute buffers rewrites + misc fixes

by Christian Costa

Hi, Sorry, for a unknown reason my wine-devel delivery had been disabled. I enabled it but I've just seen your posts in the archives... > Some comments on 'small' parts... I will have to commit the patch on > my tree > to try to understand the resulting code to understand it better [:-)] >> + if ( IsEqualGUID( &IID_IDirectDrawSurface, riid ) || >> + IsEqualGUID( &IID_IDirectDrawSurface2, riid ) || >> + IsEqualGUID( &IID_IDirectDrawSurface3, riid ) ) { >> + IDirectDrawSurface7_AddRef(ICOM_INTERFACE(This->surface, >> IDirectDrawSurface7)); >> + *obp = ICOM_INTERFACE(This->surface, IDirectDrawSurface3); >> + TRACE(" Return IDirectDrawSurface3 interface %p\n", *obp); >> + return S_OK; >> + } >> + if ( IsEqualGUID( &IID_IDirectDrawSurface3, riid ) || >> + IsEqualGUID( &IID_IDirectDrawSurface7, riid ) ) { + >> IDirectDrawSurface7_AddRef(ICOM_INTERFACE(This->surface, >> IDirectDrawSurface7)); >> + *obp = ICOM_INTERFACE(This->surface, IDirectDrawSurface7); >> + TRACE(" Return IDirectDrawSurface7 interface %p\n", *obp); >> + return S_OK; >> + } > > Well, it's a bit strange to have 'IID_IDirectDrawSurface3' twice, no > [:-)] ? This seems like the Copy/Paste syndrom [:-)] >> /* We only support the BLT with DEPTH_FILL for now */ >> - if (This->ddraw_owner->d3d != NULL) { >> + if ((dwFlags & DDBLT_DEPTHFILL) && This->ddraw_owner->d3d != >> NULL) { >> if (This->ddraw_owner->d3d->current_device != NULL) { >> >> This->ddraw_owner->d3d->current_device->clear(This->ddraw_owner->d3d->current_device, >> >> 0, NULL, /* Clear the whole screen */ > > Did you add this check here because some game were actually doing a > 'normal' > blit on the ZBuffer ? Yes! From a ZBuffer surface to another... Don't remember the game though... (because it crashed in another part of wine) > What happens in this case ? When doing the standard blit, the app set the DDBLT struct pointer to NULL so without the check this simply crashes when accessing the depthfill member of the structure. > Moreover, you could also add here (which I forgot to do in my patch), > support for the 'dst locking rectangle' in case an application tries to > clear only part of the buffer (see example in the Blt overide function in > d3ddevice/mesa.c for the 'Colorfill' case). Yes this can be done as well. [:-)] > Well, I have a comment... But it's in a part of the code that will be so > rarely used that it could be completely thrown away anyway [:-)] Sure, It's barely used. [:-)] > Basically, you are doing the full projection (without doing the clipping > though) in software... And this does not go well at all with lighting. Yes, there is no lighting yet. > This is why I choose in the previous code to only do the world > transformation to > NOT impact at all lighting (and it worked for Twist AFAIK). So I am > wondering why you choose to go all the way and did not do exactly as I > did > (basically, only do the WORLD transform and set only the PROJ / VIEW one > using the D3D7 API and set the WORLD to Identity as we already did the > transform). Because the world transformation introduced the W coordinate which cannot be passed to drawing functions. But well, this coordinate should be always be 1 after the world transformation so we can ommit it. >Even better would have been to have reused fully our VertexBuffer code and > our (hacky [:-)] ) TransformVertices code. Oh! Well I forgot this hack... [;-)] Bye Christian

June 2, 2003