January 2002 - Wine-Devel - list.winehq.org

ReadFile() question (Bug?)
by Martin Wilck Jan. 4, 2002

Jan. 4, 2002

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(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Re: [RFC] cleaner FD_TYPE_XXX implementation
by Mike McCormack Jan. 4, 2002

Jan. 4, 2002

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(a)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 Jan. 4, 2002

Jan. 4, 2002

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(a)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 Jan. 4, 2002

Jan. 4, 2002

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 Jan. 3, 2002

Jan. 3, 2002

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 Jan. 3, 2002

Jan. 3, 2002

Sylvain Petreolle wrote: > Running test1.pl returns to me : > > [syl(a)snoop winetest]$ cd /c/winetest > [syl(a)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 Jan. 3, 2002

Jan. 3, 2002

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 Jan. 3, 2002

Jan. 3, 2002

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(a)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 Jan. 3, 2002

Jan. 3, 2002

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 Jan. 2, 2002

Jan. 2, 2002

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 Jan. 2, 2002

Jan. 2, 2002

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 Jan. 2, 2002

Jan. 2, 2002

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 Jan. 2, 2002

Jan. 2, 2002

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(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Re: mvcrt.ungetc and stdio buffering
by Jon Griffiths Jan. 2, 2002

Jan. 2, 2002

>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 Jan. 2, 2002

Jan. 2, 2002

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 Jan. 1, 2002

Jan. 1, 2002

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 Jan. 1, 2002

Jan. 1, 2002

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(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

current cvs doesn't compile with freetype-2.0.3
by Ben Stanley Jan. 1, 2002

Jan. 1, 2002

Hi, I tried compiling current cvs wine on RH 7.2, and it fails... gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o freetype.o freetype.c freetype.c:43:31: freetype/ftnames.h: No such file or directory make[2]: *** [freetype.o] Error 1 make[2]: Leaving directory `/share/building/wine/wine/dlls/gdi' It seems that the autoconf test for freetype/ftnames.h doesn't work properly. The file is not present in the RH package, and is not included in the freetype-2.0.3 tarball either. BTW, I'm not on the list atm. Ben.

2 2