wine-devel January 2002

wine-devel@winehq.org

105 participants
218 discussions

Patch: 001-file_overlapped.diff
by Martin Wilck 07 Jan '02

07 Jan '02

This patch is a repost of my patch of 2002-01-03, now against the current CVS version including Mike McCormack's latest patches (01-cancelio.diff, 01-write_file_update.diff, 01-comm16_update.diff as of 2002-01-06). It is the first in a series of patches that constitute intermediate steps towards async socket IO. I consider them pretty clean and have done basic testing. My testing possibilities are limited, though - I'd be grateful to anybody who could run tests especially with 16-bit network-oriented windows applications. Bugs in my code should show up immediately as regressions. Patch file: 001-file_overlapped.diff Purpose: This patch fixes overlapped I/O on regular files. Created: 2002-01-07 Applies: CVS 2002-01-07 with Mike McCorkack's patches of 2002-01-06 applied (01-cancelio.diff, 01-write_file_update.diff, 01-comm16_update.diff) Add server side support for async IO on files. FILE_Async[Read|Write]Service and WriteFile() use pread() / pwrite() rather than read() / write () for fd's on which lseek()ing is possible to honour the fact that lpOverlapped->Offset and lpOverlapped->OffsetHigh contain the offset from which the file is to be read. files/file.c: OVERLAPPED_OFFSET: Macro to calculate file offset from OVERLAPPED struct. FILE_AsyncReadService(): Use pread() on fd's that allow lseek(). FILE_AsyncWriteService(): Use pwrite() on fd's that allow lseek(). WriteFile(): dito. server/file.c: struct file: Add two struct async_queue fields (for async read/write). file_ops: file specific poll_event() method accounts for overlapped IO. define queue_async() method. create_file_for_fd(): call init_async_queue() on overlapped files. file_poll_event(): call default_poll_event() only after checking for queued async requests. file_get_info(): return FD_TYPE_OVERLAPPED if FILE_FLAG_OVERLAPPED is set. file_queue_async(): implement queue_async() method for files. file_destroy(): destroy async queues on overlapped files. Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> diff -ruX diffignore CVS/wine/files/file.c MW/wine/files/file.c --- CVS/wine/files/file.c Mon Jan 7 15:54:59 2002 +++ MW/wine/files/file.c Mon Jan 7 15:55:36 2002 @@ -9,6 +9,9 @@ * Right now, they simply call the CopyFile method. */ +/* This is needed to avoid compile-time warnings about pread / pwrite */ +#define _GNU_SOURCE +#define _XOPEN_SOURCE 500 #include "config.h" #include "wine/port.h" @@ -55,6 +58,9 @@ /* Size of per-process table of DOS handles */ #define DOS_TABLE_SIZE 256 +/* Macro to derive file offset from OVERLAPPED struct */ +#define OVERLAPPED_OFFSET(overlapped) ((off_t) (overlapped)->Offset + ((off_t) (overlapped)->OffsetHigh << 32)) + static HANDLE dos_handles[DOS_TABLE_SIZE]; @@ -1304,12 +1310,21 @@ { LPOVERLAPPED lpOverlapped = ovp->lpOverlapped; int result, r; + int already = lpOverlapped->InternalHigh; TRACE("%p %p\n", lpOverlapped, ovp->buffer ); /* check to see if the data is ready (non-blocking) */ - result = read(ovp->fd, &ovp->buffer[lpOverlapped->InternalHigh], - ovp->count - lpOverlapped->InternalHigh); + + /* Check if this file object can lseek() */ + /* FIXME: test this only once for each file object ?? */ + if (lseek (ovp->fd, 0, SEEK_CUR) != (off_t) -1) + result = pread (ovp->fd, + &ovp->buffer[already], + ovp->count - already, + OVERLAPPED_OFFSET (lpOverlapped) + already); + else + result = read (ovp->fd, &ovp->buffer[already], ovp->count - already); if ( (result<0) && ((errno == EAGAIN) || (errno == EINTR))) { @@ -1543,12 +1558,21 @@ { LPOVERLAPPED lpOverlapped = ovp->lpOverlapped; int result, r; + int already = lpOverlapped->InternalHigh; TRACE("(%p %p)\n",lpOverlapped,ovp->buffer); /* write some data (non-blocking) */ - result = write(ovp->fd, &ovp->buffer[lpOverlapped->InternalHigh], - ovp->count-lpOverlapped->InternalHigh); + + /* Check if this file object can lseek() */ + /* FIXME: test this only once for each file object ?? */ + if (lseek (ovp->fd, 0, SEEK_CUR) != (off_t) -1) + result = pwrite (ovp->fd, + &ovp->buffer[already], + ovp->count - already, + OVERLAPPED_OFFSET (lpOverlapped) + already); + else + result = write (ovp->fd, &ovp->buffer[already], ovp->count - already); if ( (result<0) && ((errno == EAGAIN) || (errno == EINTR))) { @@ -1678,7 +1702,13 @@ } /* see if we can write some data already (this shouldn't block) */ - result = write( unix_handle, buffer, bytesToWrite ); + + if ( lseek(unix_handle, 0, SEEK_CUR) != (off_t) -1 ) + result = pwrite( unix_handle, buffer, bytesToWrite, + OVERLAPPED_OFFSET (overlapped) ); + else + result = write( unix_handle, buffer, bytesToWrite ); + close(unix_handle); if(result<0) @@ -1693,7 +1723,7 @@ result = 0; } - /* if we read enough to keep the app happy, then return now */ + /* if we wrote enough to keep the app happy, then return now */ if(result>=bytesToWrite) { *bytesWritten = result; diff -ruX diffignore CVS/wine/server/file.c MW/wine/server/file.c --- CVS/wine/server/file.c Mon Jan 7 15:54:59 2002 +++ MW/wine/server/file.c Mon Jan 7 15:55:28 2002 @@ -29,6 +29,7 @@ #include "handle.h" #include "thread.h" #include "request.h" +#include "async.h" struct file { @@ -39,6 +40,9 @@ unsigned int flags; /* flags (FILE_FLAG_*) */ unsigned int sharing; /* file sharing mode */ int drive_type; /* type of drive the file is on */ + + struct async_queue read_q; + struct async_queue write_q; }; #define NAME_HASH_SIZE 37 @@ -47,10 +51,12 @@ static void file_dump( struct object *obj, int verbose ); static int file_get_poll_events( struct object *obj ); +static void file_poll_event( struct object *obj, int event ); static int file_get_fd( struct object *obj ); static int file_flush( struct object *obj ); static int file_get_info( struct object *obj, struct get_file_info_reply *reply ); static void file_destroy( struct object *obj ); +static struct async_queue * file_queue_async(struct object *obj, struct async* async, int type, int count); static const struct object_ops file_ops = { @@ -61,11 +67,11 @@ default_poll_signaled, /* signaled */ no_satisfied, /* satisfied */ file_get_poll_events, /* get_poll_events */ - default_poll_event, /* poll_event */ + file_poll_event, /* poll_event */ file_get_fd, /* get_fd */ file_flush, /* flush */ file_get_info, /* get_file_info */ - NULL, /* queue_async */ + file_queue_async, /* queue_async */ file_destroy /* destroy */ }; @@ -116,6 +122,11 @@ file->flags = attrs; file->sharing = sharing; file->drive_type = drive_type; + if (file->flags & FILE_FLAG_OVERLAPPED) + { + init_async_queue (&file->read_q); + init_async_queue (&file->write_q); + } } return file; } @@ -253,6 +264,27 @@ return events; } +static void file_poll_event( struct object *obj, int event ) +{ + struct file *file = (struct file *)obj; + assert( obj->ops == &file_ops ); + if ( file->flags & FILE_FLAG_OVERLAPPED ) + { + if( IS_READY(file->read_q) && (POLLIN & event) ) + { + async_notify(file->read_q.head, STATUS_ALERTED); + return; + } + if( IS_READY(file->write_q) && (POLLIN & event) ) + { + async_notify(file->write_q.head, STATUS_ALERTED); + return; + } + } + default_poll_event( obj, event ); +} + + static int file_get_fd( struct object *obj ) { struct file *file = (struct file *)obj; @@ -308,9 +340,45 @@ reply->index_low = st.st_ino; reply->serial = 0; /* FIXME */ } + + if (file->flags & FILE_FLAG_OVERLAPPED) + return FD_TYPE_OVERLAPPED; + return FD_TYPE_DEFAULT; } +static struct async_queue *file_queue_async(struct object *obj, struct async *async, int type, int count) +{ + struct file *file = (struct file *)obj; + struct async_queue *q; + + assert( obj->ops == &file_ops ); + + if ( !(file->flags & FILE_FLAG_OVERLAPPED) ) + { + set_error ( STATUS_INVALID_HANDLE ); + return NULL; + } + + switch(type) + { + case ASYNC_TYPE_READ: + q = &file->read_q; + break; + case ASYNC_TYPE_WRITE: + q = &file->write_q; + break; + default: + set_error( STATUS_INVALID_PARAMETER ); + return NULL; + } + + if(async && !async->q) + async_insert(q, async); + + return q; +} + static void file_destroy( struct object *obj ) { struct file *file = (struct file *)obj; @@ -325,6 +393,11 @@ *pptr = (*pptr)->next; if (file->flags & FILE_FLAG_DELETE_ON_CLOSE) unlink( file->name ); free( file->name ); + } + if (file->flags & FILE_FLAG_OVERLAPPED) + { + destroy_async_queue (&file->read_q); + destroy_async_queue (&file->write_q); } }

1 0

mvcrt patch
by Waldek Hebisch 07 Jan '02

07 Jan '02

Enclosed is a patch (diff to 2001.12.26 snapshot) which impements stdio buffering in msvcrt. Since I cannot make Visual C binaries could anybady with Visual C++ test it? I have testet it with mingw32 and I incude my test program (iotst.c). The program prints a line indicating which test it is making and then complains about failures. Comment 1: current builtin msvcrt fails test1 (and few other as a consequence). Some native versions of msvcrt fail test 8. Comment 2: I wrote the test the way naive programmer would wrote it (IMHO). Now I think that for a testing framework we need an assert-like macro to make checking and printing code shorter and to have uniform printouts. I ommited some tests that require multiple processes (expandig file while it is read, checking that stdio buffers got flushed at exit) - I guess that doing such test in portable way is quite tricky. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

1 0

cutting teeth
by Shane Shields 06 Jan '02

06 Jan '02

hello everybody, just want to let everyone know that i (shane shields) have joined the mailing list and downloaded the latest cvs. what i want to know now is what can i do i have some c experience but mostly dos (and some windows), vb (but i dont think its relevent) and i know the windows os quite well. as i converted to linux 8 months ago and totally removed windows i would like to help with wine development with the aim of not having to use any proprietry dlls at all (to do with the core os that is). i have looked at the 20011226 version and noticed that the ole functionality is virtually nonexistant. is anyone working on that? or is there a better way to cut my teeth with wine programming. suggestions, directions and flames welcome. just remember that i am relatively new to linux programming. looking forward to joining the community Shane Shields _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

Re: WinSpool Ordinal Addition
by Alexandre Julliard 06 Jan '02

06 Jan '02

"Mark G. Adams" <mgadams(a)sympatico.ca> writes: > I came across a program which imports a function from winspool.drv via > ordinal instead of via name. Now back in February, a patch from Huw Davies > was committed which removed all the ordinals from the spec file for winspool > (see http://www.winehq.com/hypermail/wine-cvs/2001/02/0016.html). I don't > know what the reason was (maybe some were wrong?), so I've attached a patch > which re-adds the ordinal for the one function this program requires. What app is that? None of the winspool.drv I checked have PrinterProperties at ordinal 201, so I don't see how this could work. Or does it just want to have something there? does it work if you put a stub at 201 instead of PrinterProperties? -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: PATCH: Euro
by Patrik Stridvall 06 Jan '02

06 Jan '02

> This patch changes the NLS currency of all Euro countries to > use the "EUR" > as international currency and the euro-sign (iso-8859-15, > character 164). Hmm. While I'm do not doubt that some users of Wine might find this useful, Wine is supposed to do what Windows does and if Windows does something wrong Wine usually should as well. If I'm not mistaken the .nls contains that default values. It is entirely possible to change the currency and such in the registry to specify things differently for each user. That said I would find it unlikely that this patch would cause any serious problem. After all, as I said, the user can specify whatever currency it likes after the defaults have been set and every application is supposed to be able to handle it. So I do not really oppose the patch. It is more the principle I'm intrested in: Under what circumstances should Wine change the behavior if Windows does something in the wrong way?

4 3

Re: MSDOS Error Table Handling
by Ove Kaaven 05 Jan '02

05 Jan '02

On Thu, 3 Jan 2002 ccrayne(a)crayne.org wrote: > - /* We will use a snippet of real mode code that calls */ + > /* We use a snippet of real mode code that calls */ > /* a WINE-only interrupt to handle moving the requested */ - > /* message into the buffer... */ > + /* message into the buffer... ... > - INT (WINE-only interrupt) If that's what you need, I suggest allocating a DPMI Real-Mode Callback thunk using DPMI_AllocInternalRMCB(). (There's an example of how to use it in dosaspi.c... you give it a Wine-implemented function, and it returns a real-mode address that DOS apps can use to call it... the only thing to keep in mind is that it's the Wine function's responsibility to pop the real-mode stack)

2 5

Re: ReadFile() question (Bug?)
by Mike McCormack 05 Jan '02

05 Jan '02

Hi Martin, The console doesn't use an fd, so no fd will be fetched in FILE_GetUnixHandle. (have a look at server/console.c) Mike > Btw, > > in the code in ReadFile() / WriteFile() handling consoles, > shouldn't there be a > close (unix_handle) > statement before calling ReadConsoleA() / WriteConsoleA() ? > > Martin ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

SHGetSpecialFolderLocation function
by Chris Green 04 Jan '02

04 Jan '02

Hi, I've been looking into this function, trying to work out why ms office 97 can't install under Wine. (I've also been looking at the handling of command-lines when new processes are spawned, as office's setup program spawns a process called acmsetup with a string of command-line options, and it seems that wine manages to insert an extra " at the end of the command line.) What I've found though with the SHGetSpecialFolderLocation, is that it seems to me that it is designed to allow the caller to pick an arbitrary value for the CSIDL, and that this will cause windows to create a new CSIDL. As the function's implementation currently stands, it has a hard-coded table of possible CSIDLs, and rejects calls with unknown CSIDLs. Has anyone else looked at this function, and does anyone have any comments or suggestions on ways to address this? I'm thinking that these values probably need to go into the registry, or something, rather than being stored in the code... regards Chris Green

1 0

msnbc news alert installer: "Unable to start browser"
by Dan Kegel 04 Jan '02

04 Jan '02

While doing research for my site on the Microsoft antitrust trial ( http://www.kegel.com/remedy/ ), I came across a nasty little EULA for a product called MSNBC News Alert. The EULA is at http://www.msnbc.com/tools/newsalert/naeula.asp and says > MSNBC Interactive grants you the right to install and use > copies of the SOFTWARE PRODUCT on your computers running validly > licensed copies of the operating system for which the SOFTWARE > PRODUCT was designed [e.g., Microsoft Windows(r) 95; Microsoft > Windows NT(r), Microsoft Windows 3.x, Macintosh, etc.]. It'd be nice to know how close Wine is to being able to (a) install and (b) run this on a fake windows installation, as this may have some bearing on whether Microsoft is damaging anybody with this exclusionary EULA. (Besides, how could I resist? That EULA practically begs to be disobeyed!) So I downloaded it from http://www.msnbc.com/tools/newstools/d/news_alert.asp and ran it, but it failed with the dialog box "News Alert and Windows were unable to start your default browser to access the following URL..." Can anyone have a look at what's wrong (presumably Wine doesn't implement browser control, or I don't have a browser registered?) I'm running Wine release 20010731 (my, that's old!) The output of wine -debugmsg +all is at http://www.kegel.com/wine/newsalert/log.bz2 and is 328KB compressed (200 MB expanded!) I can't see anything obvious, but then I'm out of practice. (You probably just want to download the executable and try it yourself.) Thanks, Dan Kegel

5 6

Wine Tasklist
by Francois Gouget 04 Jan '02

04 Jan '02

Hi, I would like to establish two Wine tasklists in Wine's bugzilla. * the first list would contain the items listed in my previous 'Call for Volunteers' emails. This would make it easier to keep track of these tasks. * the second list would contain more complex and general items like 'DCOM support'. For the first list, refer to my previous 'Call for Volunteers' emails. I think I will start it from there and we can update it after that. For the second list, I included a first draft below. I would like your comments on it, especially with regard to the status of some of these items, and suggestions if you see missing items. I know we already have a 'Wine 1.0' and 'Wine 1.x' tasklists'. There may be some overlap but I think the intent is different. * My intent with these two new tasklists is to advertise what we want to do to potential contributors. So the idea is to then add a page to the WineHQ web site that would list all the ways one can contribute to Wine: maintaining an application entry in the Application Database, helping users on the mailing lists, buying Wine based applications, and of course contributing code. And for this last item, these lists would provide a good starting point, both for developpers with little time and for developpers who want to invest themselves more heavily in Wine. * Then unlike the 1.0 and 1.x tasklists, these new lists would not be tied to a specific Wine release or date. I hope to produce a draft of this web page in the coming days. In the meantime let me know if I missed things in the list below. For each item I tried to indicate the rationale behind the task, and point to the corresponding bugzilla report if there is one. Wine tasklist ------------- * Make the registry loadable on demand - when working from a Windows partition the registry is big. - this causes wineserver to allocate a lot of memory - this has a big impact on startup times - a 'database' based registry may be more robust * Rasterizer - to paint into a DIB we have to copy the IB contents into an X bitmap, call X functions to modify the bitmap, often only to have to copy the result back to the DIB when the application tries to read it. Imagine it for eash SetPixel operation! - a rasterizer would be able to perform these operations directly on the DIB and thus provide better performance, at least in some situations. - it would also provide better color accuracy: the X server often only supports a few bit depths so that if the application works on a 24bpp DIB but the X server is in 16bpp mode, 3bits are lost per color component. * Cross process messages - used by many applications - needed for DDE (bug 95) - Alexandre, you worked on this recently, right? Is this working now? - See bug 93 * Out of proc COM - Needed for Installshield 6 - Would probably help with at least some functionality of a host of other applications * DCOM support - same as out of proc COM but network transparent - should be interoperable with Microsoft's implementation so that, in a company setting, processes running in Wine can connect to servers running on whatever Windows server are present. * Better multi-user support - how to get per-user registry files - how much per-user setup is really necessary? (create a '.wine' directory, create per user registry files, who does that, ...) - is it possible to share a single read-only 'c:\' drive? What do we need to get parity with an NT environment? - is it possible to share a read-only 'system.reg' file? - what is the impact of a 'load on demand' registry? Could we share a single registry server? - what would be necessary to share a single - there are many options that need to be investigated and documented... * UNC path handling - for drives '\\.\e:', devices - for network paths - there's been a patch related to this recently but I believe it does not cover all cases - integrate with Samba to handle network UNC paths - provide a way to mount/unmount drives at runtime, especially network drives. One should be able to disable this in the config file (for security reasons). - Support for 'persistent' mounts... will require modifying the way w specify which drives are mounted where. - provide an applet to mount/unmount drives while Wine is running. * Native Alsa support - Alsa is the future of sound in Linux: should be integrated in 2.5 - Could it offer capabilities that OSS does not offer? - Other platforms may not support Alsa any time soon so we must keep OSS too - Anti-rational: Alsa includes an OSS compatibilty mode that seems to work pretty well - see bug 324 * aRts support - On an OSS system when the aRts daemon is running Wine cannot access the sound device - aRts makes it possible to send the sound other the network. This kind of functionality is great for a thin-client environments: setup a server and have the sound sent to each terminal ("You've got mail" ;-). Supporting aRts in Wine would let it integrate perfectly in such an environment. - this could either be native support, or making Wine compatible with artsdsp. The current problem may be related to the -Bsymbolic link option. - see bug 325 * ESounD support - Same thing as for aRts - see bug 326 - Making Wine compatible with artsdsp may also make it compatible with esddsp (and vice versa). * Write a regedit replacement - used by some installers to create registry keys - we can limit the functionality to just that although since Wine has a registry we should probably provide a tool to browse/edit it. - will be more important once we have a database based registry for the load on demand functionality * Write a regsvr32 replacement - used by some installers * Fix the desktop mode - If a process running in desktop mode start another, the new process creates a new desktop - the background is black - one cannot start a specific application in desktop mode. You have to modify the config file. * Compile with STRICT on - better type safety - reveales all the 16/32bits hacks - see bug 90 * Dll separation - to allow us to swap native dlls in and out with less problems - to make the dlls more independent of each other and make it easier to treat them as independent projects - see bug 96 * HEAP_strdup* removal - Alexandre said some day that they will go away - Part of the dll separation? * Move the winsock16 code to wsock32 - winsock16 is more related to wsock32 than to ws2_32 - ws2_32 is the new API. This would leave us with a clean 32bit implementation of the new API that is not encumbered with 16bit hacks. * Check .spec file completeness - we need complete spec file to know where we stand - determine what's new in WinMe, Win2000, WinXP - check that the ordinals/absence of ordinals is correct - I have scripts that can be used as a starting point * Winedbg expression handling - when modifying the contents of a variable there can be mixups where the debugger modifies its own memory instead of that of the debugged process. * Winedbg g++ 3.0 support - The debugging format and the ABI changed in g++ 3.0 and winedbg does not support the new ABI. - This prevents debugging of C++ Winelib applications - This is especially troublesome for MFC Winelib applications - Eric, you worked on this recently, do you know if this is a thing of the past or is it possible that there are still problems (I did not test recently) * Better memory allocator - some memory allocation/release patterns cause the current allocator to be relatively inefficient - see threads on wine-dev (Ove/Gav hit this problem) * Winelib richedit support - one of the things needed by MFC - the API seems at least partly supported, but the headers are very incomplete - see bug 330 * Visual C++ project support - make it possible to generate a Winelib project from a Visual C++ project - this should be done by extending winemaker - see bug 61 * Specify how to compile and package the MFC - many applications use the MFC. To make Winelib useful it is necessary to make it easier to compile the MFC and MFC-based applications - winemaker has some support for the MFC. But it makes suppositions about how the MFC were compiled (library names, etc.). So it is necessary to document how to get something that works well - see bug 110 -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 145 = 1! + 4! + 5!

5 9

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel January 2002