wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

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

ReadFile() question (Bug?)
by Martin Wilck 04 Jan '02

04 Jan '02

Btw, in the code in ReadFile() / WriteFile() handling consoles, shouldn't there be a close (unix_handle) statement before calling ReadConsoleA() / WriteConsoleA() ? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Re: [RFC] cleaner FD_TYPE_XXX implementation
by Mike McCormack 04 Jan '02

04 Jan '02

Hi Martin, Sorry, i should have been a little more clear: if there is a overlapped console, the code in ReadFile (ie. the implemention) will ignore the fact that it is a console, and treat it as a standard overlapped file. In other words, ReadFile should check if the fd is a console fd first, then check if it has the overlapped flag. What you're trying to do is good, and my complaint is just a quibble since the console code doesn't support overlapped operations now anyway :-] Mike Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> > >On Fri, 4 Jan 2002, Mike McCormack wrote: > >> looks good to me. The only complication i can see is if overlapped >> operations are possible on consoles. > >Yes, but the OVERLAPPED flag must be set explicitly by the get_file_info() >method of the corresponding server object. >console_get_file_info() will simply leave this flag unset if overlapped >operations are impossible on consoles. > >The idea is that get_file_info() has a more flexible way to communicate >the capabilities of a file descriptor; this doesn't imply all fields are >completely independent of each other. > >Martin ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

Re: [RFC] cleaner FD_TYPE_XXX implementation
by Mike McCormack 04 Jan '02

04 Jan '02

Hi Martin, looks good to me. The only complication i can see is if overlapped operations are possible on consoles. Mike Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> > > >The FD_TYPE_XXX macros are used in the ReadFile() and WriteFile() >routines to invoke special read/write procedures for file descriptors of >certain types. I feel that for future improvements of Wine IO, it >might be important to distinguish between FD type (regular file, serial >port, pipe, ...) and FD attributes (can do overlapped IO, uses timeout, >....). > >That is the rationale for the following small patch. >Please comment. > >Martin ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

Debugger on Solaris
by Robert Lunnon 04 Jan '02

04 Jan '02

I sent this message before but I dont think it reached the list. I am trying to make the debugger work on Solaris. The wineserver and debugger currently co-operate using ptrace to debug a client app, but on solaris the debugger deadlocks. It was previously thought that this was due to the threading model on Solaris which is different. (Different threads don't have different pids). The ptrace manual says that a client must call ptrace(PTRACE_TRACEME...) before it can be debugged but grepping the Wine source can find no useful references to TRACEME. Without calling ptrace (TRACEME,...) Solaris returns ESRCH even though the process exists which causes the wineserver to assume the process is defunct and delete the app, apparently causing the deadlock (This deadlock will have to be fixed too !). Can anyone enlighten me as to what gotchas there are in fixing this since I don't know much about Linux behaviour (Though the linux ptrace mentions PTRACE_TRACEME too but apparently doesn't enforce it !) Bob

2 2

Re: We *really* need a development model change !
by Andreas Mohr 03 Jan '02

03 Jan '02

On Thu, Jan 03, 2002 at 04:55:03PM -0500, Robert Baruch wrote: > On Thursday 03 January 2002 07:54 am, Andriy Palamarchuk wrote: > The value is when you add new functionality (and possibly new tests) and old > tests break. Then you can pinpoint the changes that caused the old tests to > break. Again, that can only work if all the old tests succeeded, which means > you can't include tests that you know will fail in a release. No, you can ! This is exactly what everybody seems to assume we don't need: tests that are *known* to fail. (like Ulrich Weigand said: have status variables like FAIL, XFAIL, GOOD, XGOOD) The key to success is to check the *difference* to *expected* behaviour. And if there is indeed a *difference*, then we know that something changed and we need to examine it more closely and thus derive our ultimate result codes from it. Again, we can't just include tests that work on all occasions. Instead we should have tests that are as thorough/strict as possible, and thus with all sorts of failures, but which ultimately don't let the test suite fail, since they're *expected* to currently fail. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

2 1

Re: We *really* need a development model change !
by Andriy Palamarchuk 03 Jan '02

03 Jan '02

Sylvain Petreolle wrote: > Running test1.pl returns to me : > > [syl@snoop winetest]$ cd /c/winetest > [syl@snoop winetest]$ perl test1.pl > Can't locate wine.pm in @INC (@INC contains: > /usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0 > /usr/lib/perl5/site_perl/5.6.0/i386-linux > /usr/lib/perl5/site_perl/5.6.0 > /usr/lib/perl5/site_perl .) at test1.pl line 8. > BEGIN failed--compilation aborted at test1.pl line > 8.--- Sorry, I was not specific enough about the scripts launching instructions. It looks like you try to start the script from directory, which does not have wine.pm module. You need to put contents of the archive to directory "programs/winetest" of the wine source tree, build winetest application, then it will work. This directory should have wine.pm. Because of the problems I reported in the message (see below) the scripts require different launching. You can start the scripts as: # this script uses winetest framework winetest test1.pl #these don't perl test2.pl perl test_all.pl [...] >>However I found a few issues with winetest: >>1) For some reason running test_all.pl with winetest >>gives compilation error. I saw the same compilation >>error when I tried to use other Perl testing >>framework >>Test::Unit. >>2) Compilation failure when I try to run test1.pl >>directly with Perl, like "perl test1.pl" Let me know if you still can't start the scripts. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

2 1

Re: We *really* need a development model change !
by Andriy Palamarchuk 03 Jan '02

03 Jan '02

Alexandre Julliard wrote: > Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: >>Please comment on both my intended posting and the way I programmed the first >>version of the test suite (I'm not extremely happy with the current program; >>if you have any improvements, then get them here ASAP !). > > Look at programs/winetest, that's the tool we should use to write > tests IMO. Just looked at the tool. It only provides gateway from Perl to wine API functions, right? Advantages I see in using script-based tests: 1) tests can be used without recompilation 2) Perl is familiar to many developers 3) programming in scripting language is usually easier than in C 4) Perl is widely used for testing purposes and I expect to find many testing tools in Perl. Cons: 1) Many current Wine contributors don't know Perl 2) one more level of abstraction does not give significant advantages in this application. On the contrary, it is more difficult to locate cause of problems because developer has to go trough one more, often not familiar layer. Absense of strict typing in this layer will hurt a lot. Advantages of using C-based tests: 1) compilation has to be used to run the tests. In some cases this is an advantage. Before running the tests you'd better be sure it at least compiles in both environments. 2) C is the most familiar to developers language and the language itself is simpler than Perl 3) Documentation for Win32 API is C-oriented. Examples, given in documentation are in C or easy translated to C 4) Developers already have some testing code snippets in C Summary: Requirements to the unit testing tool: 1) should help to quickly create tests 2) easy to use, should help to involve as many developers as possible. 3) may be useful for developers, using Wine for there projects Because of the goals I'm more inclined to use C-based test suite. IMHO it is better suited for existing Wine developers audience and will provide us much bigger code pool. I'm even ready to have tests in both - Perl and C. The big question is a tool to test GUI. I did not find any OS Windows GUI testing frameworks :-( Comments, suggestions? Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

11 60

[RFC] cleaner FD_TYPE_XXX implementation
by Martin Wilck 03 Jan '02

03 Jan '02

The FD_TYPE_XXX macros are used in the ReadFile() and WriteFile() routines to invoke special read/write procedures for file descriptors of certain types. I feel that for future improvements of Wine IO, it might be important to distinguish between FD type (regular file, serial port, pipe, ...) and FD attributes (can do overlapped IO, uses timeout, ...). That is the rationale for the following small patch. Please comment. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy diff -ruw -X diffignore CVS/wine/files/file.c MW/wine/files/file.c --- CVS/wine/files/file.c Wed Jan 2 12:50:02 2002 +++ MW/wine/files/file.c Thu Jan 3 14:55:13 2002 @@ -1436,9 +1436,8 @@ unix_handle = FILE_GetUnixHandleType( hFile, GENERIC_READ, &type ); - switch (type) + if ( FD_TYPE_IS_OVERLAPPED (type) ) { - case FD_TYPE_OVERLAPPED: if (unix_handle == -1) return FALSE; if ( (overlapped==NULL) || NtResetEvent( overlapped->hEvent, NULL ) ) { @@ -1481,15 +1480,21 @@ /* fail on return, with ERROR_IO_PENDING */ SetLastError(ERROR_IO_PENDING); return FALSE; + } - case FD_TYPE_CONSOLE: + else if ( FD_TYPE (type) == FD_TYPE_CONSOLE ) + { return ReadConsoleA(hFile, buffer, bytesToRead, bytesRead, NULL); + } - case FD_TYPE_TIMEOUT: + else if ( FD_TYPE_HAS_TIMEOUT (type) ) + { close(unix_handle); return FILE_TimeoutRead(hFile, buffer, bytesToRead, bytesRead); + } - default: + else + { /* normal unix files */ if (unix_handle == -1) return FALSE; @@ -1499,7 +1504,6 @@ SetLastError(ERROR_INVALID_PARAMETER); return FALSE; } - break; } /* code for synchronous reads */ @@ -1639,9 +1643,8 @@ unix_handle = FILE_GetUnixHandleType( hFile, GENERIC_WRITE, &type ); - switch (type) + if ( FD_TYPE_IS_OVERLAPPED (type) ) { - case FD_TYPE_OVERLAPPED: if (unix_handle == -1) return FALSE; if ( (overlapped==NULL) || NtResetEvent( overlapped->hEvent, NULL ) ) { @@ -1652,12 +1655,17 @@ } /* FIXME: try write immediately before starting overlapped operation */ return WriteFileEx(hFile, buffer, bytesToWrite, overlapped, FILE_OverlappedComplete); + } - case FD_TYPE_CONSOLE: + else if ( FD_TYPE (type) == FD_TYPE_CONSOLE ) + { TRACE("%d %s %ld %p %p\n", hFile, debugstr_an(buffer, bytesToWrite), bytesToWrite, bytesWritten, overlapped ); return WriteConsoleA(hFile, buffer, bytesToWrite, bytesWritten, NULL); - default: + } + + else + { if (unix_handle == -1) return FALSE; } diff -ruw -X diffignore CVS/wine/server/device.c MW/wine/server/device.c --- CVS/wine/server/device.c Wed Jan 2 12:50:05 2002 +++ MW/wine/server/device.c Thu Jan 3 14:46:50 2002 @@ -83,7 +83,7 @@ reply->index_low = 0; reply->serial = 0; } - return FD_TYPE_DEFAULT; + return FD_TYPE_DEVICE; } /* create a device */ diff -ruw -X diffignore CVS/wine/server/file.c MW/wine/server/file.c --- CVS/wine/server/file.c Wed Jan 2 12:50:05 2002 +++ MW/wine/server/file.c Thu Jan 3 14:53:56 2002 @@ -276,6 +276,7 @@ { struct stat st; struct file *file = (struct file *)obj; + int fd_type = FD_TYPE_DEFAULT; assert( obj->ops == &file_ops ); if (reply) @@ -308,7 +309,10 @@ reply->index_low = st.st_ino; reply->serial = 0; /* FIXME */ } - return FD_TYPE_DEFAULT; + + if ( file->flags & FILE_FLAG_OVERLAPPED ) + fd_type |= FD_TYPE_FLAG_OVERLAPPED; + return fd_type; } static void file_destroy( struct object *obj ) diff -ruw -X diffignore CVS/wine/server/named_pipe.c MW/wine/server/named_pipe.c --- CVS/wine/server/named_pipe.c Wed Jan 2 12:50:05 2002 +++ MW/wine/server/named_pipe.c Thu Jan 3 14:50:17 2002 @@ -197,7 +197,7 @@ reply->index_low = 0; reply->serial = 0; } - return FD_TYPE_DEFAULT; + return FD_TYPE_NAMED_PIPE; } static struct named_pipe *create_named_pipe( const WCHAR *name, size_t len ) diff -ruw -X diffignore CVS/wine/server/pipe.c MW/wine/server/pipe.c --- CVS/wine/server/pipe.c Wed Jan 2 12:50:05 2002 +++ MW/wine/server/pipe.c Thu Jan 3 14:50:29 2002 @@ -140,7 +140,7 @@ reply->index_low = 0; reply->serial = 0; } - return FD_TYPE_DEFAULT; + return FD_TYPE_PIPE; } static void pipe_destroy( struct object *obj ) diff -ruw -X diffignore CVS/wine/server/protocol.def MW/wine/server/protocol.def --- CVS/wine/server/protocol.def Wed Jan 2 12:50:05 2002 +++ MW/wine/server/protocol.def Thu Jan 3 14:53:27 2002 @@ -544,12 +544,22 @@ int fd; /* file descriptor */ int type; /* the type of file */ @END +#define FD_TYPE(x) ((x) & 0xff) + #define FD_TYPE_INVALID 0 #define FD_TYPE_DEFAULT 1 #define FD_TYPE_CONSOLE 2 -#define FD_TYPE_OVERLAPPED 3 -#define FD_TYPE_TIMEOUT 4 +#define FD_TYPE_DEVICE 3 +#define FD_TYPE_NAMED_PIPE 4 +#define FD_TYPE_PIPE 5 +#define FD_TYPE_SERIAL 6 +#define FD_TYPE_SOCKET 7 + +#define FD_TYPE_FLAG_OVERLAPPED 0x100 +#define FD_TYPE_FLAG_TIMEOUT 0x200 +#define FD_TYPE_IS_OVERLAPPED(x) ((x) & FD_TYPE_FLAG_OVERLAPPED) +#define FD_TYPE_HAS_TIMEOUT(x) ((x) & FD_TYPE_FLAG_TIMEOUT) /* Set a file current position */ @REQ(set_file_pointer) diff -ruw -X diffignore CVS/wine/server/serial.c MW/wine/server/serial.c --- CVS/wine/server/serial.c Wed Jan 2 12:50:05 2002 +++ MW/wine/server/serial.c Thu Jan 3 14:54:09 2002 @@ -192,6 +192,7 @@ static int serial_get_info( struct object *obj, struct get_file_info_reply *reply ) { struct serial *serial = (struct serial *) obj; + int fd_type = FD_TYPE_SERIAL; assert( obj->ops == &serial_ops ); if (reply) @@ -209,13 +210,13 @@ } if(serial->attrib & FILE_FLAG_OVERLAPPED) - return FD_TYPE_OVERLAPPED; + fd_type |= FD_TYPE_FLAG_OVERLAPPED; - if( (serial->readinterval == MAXDWORD) && - (serial->readmult == 0) && (serial->readconst == 0) ) - return FD_TYPE_DEFAULT; + else if( !((serial->readinterval == MAXDWORD) && + (serial->readmult == 0) && (serial->readconst == 0)) ) + fd_type |= FD_TYPE_FLAG_TIMEOUT; - return FD_TYPE_TIMEOUT; + return fd_type; } static void serial_poll_event(struct object *obj, int event) diff -ruw -X diffignore CVS/wine/server/sock.c MW/wine/server/sock.c --- CVS/wine/server/sock.c Wed Jan 2 12:50:05 2002 +++ MW/wine/server/sock.c Thu Jan 3 14:53:11 2002 @@ -288,7 +288,7 @@ reply->index_low = 0; reply->serial = 0; } - return FD_TYPE_DEFAULT; + return FD_TYPE_SOCKET; } static void sock_destroy( struct object *obj )

1 0

[Shrinker] Another landmine
by Robert Baruch 03 Jan '02

03 Jan '02

More stepping through the code, comparing Windbg to gdb, and I found another landmine. Shrinker gets the address of the NTDLL procedure LdrAccessResource, and looks for this code: FF74XXXX push [esp+X] E8XXXXXXXX call .... Instead, it finds an unimplemented procedure in Wine. So now I will look at LdrAccessResource (and friends) to see what's involved in implementing it, whatever it is. --Rob

7 11

Mixed-mode CD Labels
by Chris Green 02 Jan '02

02 Jan '02

Hi, I've just experimentally, in my own copy of the CVS, changed the code in misc/cdrom.c so that it handles mixed mode CDs the same as data CDs for retrieving CD labels. (In the process of trying to get Age of Empires 1 to run in single-player mode). And surprisingly, it worked! (mind you AOE is not fast under wine, but that's another problem). Does anyone have any comments on this approach? if not I'll submit a patch... regards Chris Green

5 12

winelib, CRT_INIT
by Bill Medland 02 Jan '02

02 Jan '02

Does anyone know how _CRT_INIT should interact with winelib? I have a load of code which uses it in the DllMain but I presume that it is a Microsoft hack that the compiler/linker cleverly converts to something else Bill

1 0

Re: some other console fixes
by Marcus Meissner 02 Jan '02

02 Jan '02

On Tue, Jan 01, 2002 at 05:47:26PM +0100, eric pouech wrote: > as spotted by Marcus, but only half done, the fg & bg colors were > inverted > moreover, this patch also some initialisation problems in wineconsole Oh, sorry for not fixing correctly. Eric, I have also found following additional problems: - The Apply button in the Propertysheet never gets enabled. It always stays grayed out. When I press [Ok], the changes do get active, but are not saved into the registry. Somehow the property sheet does not get noticed that values inside it have changed... I do not have a clue how that works. - The default font is not fixed pitch. This is strange, since the font enum appears correct. I hardcoded the default font to Console, but this is not a good solution. Testing now appears to provide only correct fonts. Strange. - IDA text display is slow, it does a lot of redraws all the time. I tried the following patch, which makes redraws async: Index: user.c =================================================================== RCS file: /home/wine/wine/programs/wineconsole/user.c,v retrieving revision 1.4 diff -u -r1.4 user.c --- user.c 2002/01/01 00:14:02 1.4 +++ user.c 2002/01/02 18:59:18 @@ -501,7 +501,9 @@ r.bottom = (bm - data->curcfg.win_pos.Y + 1) * data->curcfg.cell_height; InvalidateRect(PRIVATE(data)->hWnd, &r, FALSE); WCUSER_FillMemDC(data, tp, bm); + /* UpdateWindow(PRIVATE(data)->hWnd); + */ } } However, while the redraws do work, they are coming very late sometimes, as if repaints do not appears frequently enough. Strange. - Mouse presses should be sent as input events. If I get too annoyed I just can just implement it ;) - wineconsole without arguments crashes: 6 faulted at EIP=0x00000043, CR2=0x00000000, EAX 0x00000001 EBX 0x401ed0bc, ECX 0x40596cec, EBP 0x40596e18 EDI 0x00000000, ESP 0x002b:0x40596e08 FS 0x008f, pid 1189 exception 0xc000001d at address 0x00000043, fs 8f, pid 1189 () wine: Unhandled exception, starting debugger... err:seh:start_debugger Couldn't start debugger ((null)) (0) Read the Wine Developers Guide on how to set up winedbg or another debugger Ciao, Marcus

2 1

[PATCH] Async IO on regular files
by Martin Wilck 02 Jan '02

02 Jan '02

This patch implements asynchronous I/O on regular file objects. It is against the current (02/01/02) CVS version of wine. I know that async IO on regular files is pretty pointless at the moment, but it's better to have it working as expected, I guess ... The patch was successfully tested with a simple test program that checks the sequence of scheduled reqeuests and file positioning via the lpOverlapped->Offset and OffsetHigh fields. server/file.c: struct file: add two async_queue fields (read/write) for async IO. create_file_for_fd(): Intialize async queues. destroy_file(): destroy async queues. file_poll_event(): invoke async requests for overlapped files. file_queue_async(): implement the queue_async() method. file_get_info(): return FD_TYPE_OVERLAPPED for overlapped files. files/file.c: FILE_AsyncReadService(): Use pread() for fd's that support seeking. FILE_AsyncWriteService(): Use pwrite() for fd's that support seeking. Regards Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Re: mvcrt.ungetc and stdio buffering
by Jon Griffiths 02 Jan '02

02 Jan '02

>Have a look at the following two messages from Marcus Meissner to >wine-devel and wine-patches: Hmm, those links dont work for me, however I remember: The header files for stdio have macro versions of putc/getc so your implementation must use the FILE structure fields in a binary compatable way (as they are currently; I implemented the code to pretend that the buffer is alway empty and needs to be reread/put on every operation). Provided you can make optimised VC++ compiled programs (i.e. those that use the macro version of get/putc) work, you dont have any extra threading issues that the code should handle already (but probably doesn't; large sections are not yet thread safed). The performance improvement would be significant also. You should make sure you test your changes thoroughly tho, as the file code is rather vital to avoiding needing native msvcrt ;-) Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

1 0

Windows NT/2000 Native API Reference by Nebbett
by Dan Kegel 02 Jan '02

02 Jan '02

I have the dubious distinction of having hired a friend back in 1997 to write perhaps the first PE compressor utility. It eventually became the core of http://www.neoworx.com/products/neolite/ (a competitor to Shrinker). He mentioned recently that he found "Windows NT/2000 Native API Reference" by Gary Nebbett http://www.amazon.com/exec/obidos/ASIN/1578701996/ to be useful in updating his compressor to handle .exe's that use some of the newer API calls. http://kt.linuxcare.com/kernel-traffic/kt20000724_77.epl mentions it, too, as do many posts in comp.os.ms-windows.programmer.nt.kernel-mode, so it appears to be useful. Just thought I'd mention that book in case anyone here hasn't heard of it. - Dan

1 0

What have I done to my debugger?
by Bill Medland 01 Jan '02

01 Jan '02

I'm getting the wrong sort of terminal. Why? I vaguely remember doing something to the registry settings for the debugger about a month ago but I can't remebber what. Since then I have not been tripping it anyway. However I am now investigating a problem that does trip the debugger. However it now comes up with an enormous terminal of some sort with terrible font and bad agreement between font and cursor positioning, so that important data disappears off the right of the screen before wrapping. However in the old days it used to use an xterm. I'd like to go back to that. Did I do that or is it a result of the stuff going on with the debugger? TIA Bill p.s. Merry Christmas to all.

3 6

Re: mvcrt.ungetc and stdio buffering
by Mike McCormack 01 Jan '02

01 Jan '02

Hello Waldek, Have a look at the following two messages from Marcus Meissner to wine-devel and wine-patches: Mon, 23 Jul 2001 09:08:31 -0400 http://www.integrita.com/cgi-local/lwgate.pl/WINE-DEVEL/archives/2001- 07/date/article-185.html Sat, 21 Jul 2001 09:14:03 -0400 http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/archives/200 1-07/date/article-102.html You can probably also use the native MSVCRT.DLL, from your windows installation. Mike > Recently I tried to run g77 compiled Fortran program under Wine. > It seems that to do any input g77 uses `ungetc'. Currently, > Wine msvcrt has unbufferd stdio. I would like to add buffering > and implement `ungetc'. Are there any traps (thread safety ??) > or will strightforward implementation work ? > -- > Waldek Hebisch > hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl ------------------------------------------ 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

Jump to page:

2025

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