- Wine-Devel - list.winehq.org

CreateFile("conin$") issue
by Oleg Prokhorov June 3, 2003

June 3, 2003

Hello , I've been examining compatibility of OpenWatcom C/C++ compiler with Wine. And it works just fine except one thing. So I request for your help to eliminate it, it looks easy but covers wine client/server stuff, which is not so trivial. Watcom's getch() uses CreateFile("conin$") to get console input handle and fails with Wine :( Here's the short code. ----------------------- CUT #include <stdio.h> #include <windows.h> int main(void) { HANDLE h; h = CreateFile( "conin$", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0 ); printf("%X", h); fflush(NULL); return 0; } ----------------------- with Windows it works just fine, but fails with Wine - CreateFile returns invalid handle == 0xFFFFFFFF. And another thing is that the bug is not reproducible under any debugger (e.g. winedbg), the code runs just fine and createfile returns true handler. -- Best regards, Oleg mailto:xolegpro(a)rbcmail.ru

2 5

Re: Re: msdos/int21 CREAT special cases
by Pouech Eric DMI AEI CAEN June 3, 2003

June 3, 2003

please stop using krnl386.exe export when possible (especially for dos emulation which is going out of kernel32/krnl386.exe combo). So, if CreateFile can do, please use it (ditto for any other krnl386 file related functions) this is needed for proper DLL separation > Hmm, and is there a reason to not do it in _lcreat16() instead? > Or is _lcreat16() really "clever" enough to handle volume labels > "properly" if called directly? > Somehow I doubt it... ;) > Or in fact you could walk further up the chain and maybe find that even > _lcreat() should be the function to have that check instead... > (or, for that matter, even CreateFileA and thus CreateFileW...) > > So my rough guess is that this should probably be prevented in CreateFileW > instead even.

3 4

Re: Add root drive mapping to default config file
by puoti June 3, 2003

June 3, 2003

Adding / to the default config file is a very bad idea, I remember reading somewhere on the net that once someone opened his mail with kmail, KDE started the attachment (A windows virus) with wine, and the virus sent itself to other users on the net. I don't remembered the details, but I do remember that the virus could get out the the net because of that / being in the wine config. So having / in the default config file is a very very bad idea, because these problems could happen again in the future. A solution to get people to have a good configuration, would be to have winsetuptk as a "official" winehq utility, and recommending people to use it to set up wine, but unfortunately winsetuptk puts / in the config file, but that can be changed. It also maps all the removable drives. BTW I've added binaries and source of winesetuptk to the wine sourceforge page, the license is gpl.

4 3

Re:_Add_root_drive_mapping_to_default_config_file
by puoti June 3, 2003

June 3, 2003

>The only thing that the / access gave Klez was (potentially) more files >to harvest email addresses from. As far as drive access, the author was >much more concerned about having write access to the home directory. If >anybody is interested, here is the article: > >http://articles.linuxguru.net/view/198 > >BTW, I do not object to having access to the root drive, but what does >a *windows* program really gain from that? Viewing system config files >in notepad? ;-> Is it just a solution in search of a problem? That's the article I read, I don't think there's any reason for having / in the config file, if klez used it, other viruses may use / to infect and spread via linux boxes in the future.

2 1

Status page update #1
by Tom June 3, 2003

June 3, 2003

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. I am aware that some Component's are not being worked on at all times... I would just like to get all workers in place. Also if your listed as a worker and your not the current worker or don't plan to work on a Component in the future I will remove you if you wish. Thanks Tom ----------------- Wine Status - Core : http://www.winehq.org/?page=status_wine Registry handling X11 display/window driver Clipboard handling Standard Windows Controls VxDs CPU emulation Multi-user support Initial registry contents Initial directory structure Initial INI files Wine Status DLL's : http://www.winehq.org/?page=status_dlls comdlg32: Common Dialogs riched32: Rich Text Control tapi32: Telephony API (TAPI) rasapi32: Dial-Up Networking (DUN) and Remote Access Service (RAS) quartz: DirectShow core wing: WinG 16-bit game library olecli32: OLE client library olesvr32: OLE server library oledlg: OLE user interface odbc32: ODBC Database Manager wnaspi32: Advanced SCSI Peripheral Interface

3 2

Re: Merge of WineX's (LGPL licensed) wininet.dll code
by Robert Shearman June 2, 2003

June 2, 2003

> 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

1 0

Re: Merge of WineX's (LGPL licensed) wininet.dll code
by Mike Hearn June 2, 2003

June 2, 2003

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 -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

2 1

Re: kernel32 file operations and wildcard filenames
by Pouech Eric DMI AEI CAEN June 2, 2003

June 2, 2003

> Under Windows (2K) all functions such as DeleteFile, CopyFile, MoveFile, > CreateDirectory and such do return FALSE and normally set the last error > to ERROR_INVALID_NAME (123) if one of the filenames passed in contains a > wildcard (*?). > > Wines kernel32 behaves somewhat different. Apart from returning different > last errors in most cases such as: > > DeleteFile: ERROR_FILE_NOT_FOUND (2) > CopyFile: ERROR_BAD_PATHNAME (161) > MoveFile: ERROR_FILE_NOT_FOUND (2) when source contains wildcards > > which all wouldn't really be a to big issue, there is one thing which > seems not right at all to me: > > MoveFile with a valid existing source and a target with wildcards > will create a file on disk containing wildcards in its name. This > certainly can't be the intention! > > So according to Win2K it would be probably useful to check in all those > functions for existence of wildcards in the input file paths and refuse > them properly. > > I took a look at the kernel32 file.c functions and saw that they usually > all call DOSFS_GetFullName which is supposed to check for valid filenames > and such. Problem is this function is also used in many other places and > I can't get a good idea if those might need to accept wildcards in file > names. > > Is there anyone more familiar with the kernel32 implementation in Wine > who could maybe give me some insight if an according change to > DOSFS_GetFullName would be useful or rather cause possible regressions? > > Otherwise the best thing to do would probably be to add explicit wildcard > tests to all those file function and refuse with an according last error > set. If I do not get any reactions this is probably what I will do as I'm > somewhat weary to change an internal low level function such as > DOSFS_GetFullName without some third party encouragement. those functions are likely to be rewritten RSN (and DOSFS_GetFullName may even disappear) So I'd suggest rather starting by writing test cases for those functions so we could use those tests when the rewrite is going to take place A+

3 2

Wierd random spew to the terminal
by Mike Hearn June 2, 2003

June 2, 2003

Hmm, I think quite a few of us have seen this now. Well, it just happened again so this time I attached gdb and tried to get a backtrace to see what was going on. I found a very curious thing.... the stack trace was huge, in fact, it had 3162 frames. As you might expect it was recursive. It looked like this: #3141 <signal handler called> #3142 0x4009e977 in rwlock_real_init (rwlock=0x42126020) at ../../include/winbase.h:1932 #3143 0x4009ea48 in __pthread_rwlock_rdlock (rwlock=0x42126020) at ../../scheduler/pthread.c:547 #3144 0x4202365a in __dcigettext () from /lib/i686/libc.so.6 #3145 0x42022ed5 in dcgettext () from /lib/i686/libc.so.6 #3146 0x4207a4b7 in strerror_r () from /lib/i686/libc.so.6 #3147 0x4206148b in perror () from /lib/i686/libc.so.6 #3148 0x40099259 in server_protocol_perror (err=0x400bdc31 "read") at ../../scheduler/client.c:134 #3149 0x40099388 in read_reply_data (buffer=0x405ca5a4, size=64) at ../../scheduler/client.c:195 #3150 0x400993de in wine_server_call (req_ptr=0x405ca5a4) at ../../scheduler/client.c:209 #3151 0x400a8653 in send_debug_event (rec=0x405ca6a8, first_chance=1, context=0x405ca71c) at exception.c:137 #3152 0x400a87fa in EXC_RtlRaiseException (rec=0x405ca6a8, context=0x405ca71c) at exception.c:195 #3153 0x400b6e48 in do_segv (context=0x405ca71c, trap_code=14, cr2=0x18, err_code=4) at signal_i386.c:814 #3154 0x400b7324 in segv_handler (__signal=11, __context= {sc_gs = 143, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1108452444, sc_esi = 1108500512, sc_ebp = 1079815400, sc_esp = 1079815380, sc_ebx = 1074654520, sc_edx = 1108500512, sc_ecx = 1108481382, sc_eax = 0, sc_trapno = 14, sc_err = 4, sc_eip = 1074391415, sc_cs = 35, __csh = 0, sc_eflags = 66050, esp_at_signal = 1079815380, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 2415929859, cr2 = 24}) at signal_i386.c:436 #3155 <signal handler called> So it would appear that there is a crash in the exception handler which just goes round and round, and clearly at some point garbage is written to stdout/stderr. Unfortunately my code-fu is not strong in areas related to threading/exception handling, so I don't really know what's going wrong, except that it seems there is a problem in rwlock_real_init (in fact the line number it gives is in GetProcessHeap()). Well, I thought somebody may find it useful. BTW, after I attached to wine (ie stopped it) something was still typing out letter by letter "xtermxtermxterm" over and over again.... wake up neo :) thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

4 4

Re: Bidi B2 - GetCharacterPlacement order array
by Dimitrie O. Paun June 2, 2003

June 2, 2003

On May 31, 2003 05:45 am, Shachar Shemesh wrote: > + /* Treat the case where no special handling was requested in a > fastpath way */ + /* copy will do if the GCP_REORDER flag is not set > */ > + if (lpResults->lpOutString) > + for (i = 0; i < nSet && lpString[i] != 0; ++i) > + lpResults->lpOutString[i] = lpString[i]; What about a strncpy here: + if (lpResults->lpOutString) + strncpyW(lpResults->lpOutString, lpString, nSet); -- Dimi.

5 7