April 2006 - Wine-Devel - list.winehq.org

Re: Stub Implementation of FSCTL_LOCK_VOLUME and FSCTL_UNLOCK_VOLUME in NtFsControlFile() in ntdll
by Mike McCormack April 25, 2006

April 25, 2006

Bernd Buschinski wrote: > + case FSCTL_LOCK_VOLUME: > + case FSCTL_UNLOCK_VOLUME: > + io->u.Status = STATUS_SUCCESS; > + break; Shouldn't this have a FIXME showing that we're not doing something? Mike

1 0

Re: riched20: EM_GETLINE implementation and test (resend)
by Mike McCormack April 25, 2006

April 25, 2006

tkho(a)ucla.edu wrote: > + memcpy(dest, L"\r", nEndChars*2); Wide character strings aren't portable. Please use something like: static const WCHAR szsr[] = { '\r', 0 }; Mike

1 0

Re: HTML e-mails
by Tony Lambregts April 24, 2006

April 24, 2006

Vitaliy Margolen wrote: > I'm sure that everyone of us really enjoys seeing influx of these > wonderful HTML messages. > > People please don't send HTML e-mails to the mailing lists. Tey are a pain > to read. And if some one about to say that's not their fault because they > use gmail - then DON'T use gmail for this mailing list. Or configure it > so it does not send HTML messages. > > Vitaliy > The main problem with using the Gmail web interface to send emails is that at present there is no way of specifying that a certain address always gets plain text. So if you have just sent a "Rich formatted"(HTML) message you have to remember change the setting back to "Plain text". Seeing as I almost never send "Rich formatted"(HTML) messages anyway this is not a problem for me. Sending from gmail.... -- Tony Lambregts

2 1

Web forums - simple suggestion
by Jeremy White April 24, 2006

April 24, 2006

Okay, so I've followed this thread, and I have a range of thoughts and what I think is a simple solution. First of all, if disk space is an issue, it's easily corrected with a $100 IDE drive. I think the real issue is that Jer doesn't like to work on half baked ideas unless they're more fully baked or someone else he trusts is cooking in the kitchen :-/. Second of all, it seems to me that the biggest problem is simply one of presentation. This is the relevant page: http://www.winehq.org/site/forums The current information is really quite poorly presented. There is way too much information; the useful bits (the Gmane and Google links) are buried way to deep imho. Third, I think the biggest problem is that there are 2 places to go for help. The wine-users mailing list, and the legacy usenet newsgroup. For a while, the two were connected, until the old gateway we were using broke down, and Jer ripped his hair out trying to make it work. But time has passed, and now Mailman has a builtin news <--> mail gateway system, and maybe we can reconnect them. (I'll go discuss this with Jer; if I'm not heard from ever again, it's because he beat me to a pulp with his printout of the Mailman manuals <grin>). But if we can reconnect them, then I think a nice solution would be to retool that page so the Google interface pops out: http://groups.google.com/group/comp.emulators.ms-windows.wine That looks forumishy enough to me to satisfy many people, and yet is nicely backwards compatible with all current systems. Cheers, Jeremy

4 6

Bug when using FlashFXP still exists
by liefie diefie April 24, 2006

April 24, 2006

FlashFXP (and other programs might as well) crash when trying to list. There was a patch submitted but that patch doesn't work unfortunately. Here you can see the details of it: http://www.winehq.org/pipermail/wine-devel/2005-April/035687.html I hope there will be somebody who is willing to give this a second look. You can always contact me for testing. Thank you.

1 0

NetUserGetInfo and unsupported levels
by Aidan Thornton April 24, 2006

April 24, 2006

Hi, Is there any particular reason why NetUserGetInfo returns success if it's called with a valid but unsupported value for level? This seems to cause problems for at least MSYS (part of MinGW), as it assumes this means that *bufptr has been set to something valid, when in fact the function call hasn't done this, or indeed anything much. (See bug #4488.) Aidan Thornton

2 2

Re: KERNEL: [2/2] changed test for FindFirstFileEx (Edited)
by Eric Pouech April 24, 2006

April 24, 2006

Konstantin Petrov wrote: > (Patch edited) > There were the problem while I advert to dosdevices through WINE. I made the > test (Windows vs Wine), which shows that in Windows there are available > dosfiles (such as NUL, COM1, COM2,.., LPT1, ..), and in Wine aren't. The > characteristic property of these files is that I can advert to them only > directly. In other cases they are invisible. > > patch for test > > changelog > tests/file.c: added test of FindFirstFileA to check correct handling > of > advertments to dosdevices. in you test cases, it would be worthwhile to test: - that the dos devices are only used when the full name is used, and not in other cases (like with trailing ' ', or a trailing dot '.', or even a wild card) - FindNextFileEx should also be checked to ensure the enumeration stops after the first one A+ -- Eric Pouech

1 0

Re: KERNEL: [1/2] fixed FindFirstFileExW; support for dosdevices (NUL, LPT[1-9], COM[1-9]...) (Edited)
by Eric Pouech April 24, 2006

April 24, 2006

Konstantin Petrov wrote: > (Patch Edited) > There were the problem while I advert to dosdevices through WINE. I made the > test (Windows vs Wine), which shows that in Windows there are available > dosdevices-files (such as NUL, COM1, COM2,.., LPT1, ..), and in Wine aren't. > The characteristic property of these files is that I can advert to them only > directly. In other cases they are invisible. > > patch for FinFrstFileExW > > changelog > file.c: fixed FindFirstFileExW for correct work with dosdevices. HI Konstantin, a couple of comments on your patch > > > ------------------------------------------------------------------------ > > Fix dosdevice finding (by argentum(a)etersoft.ru) > > Index: dlls/kernel/file.c > =================================================================== > RCS file: /home/wine/wine/dlls/kernel/file.c,v > retrieving revision 1.51 > diff -u -p -u -r1.51 file.c > --- dlls/kernel/file.c 3 Apr 2006 19:46:58 -0000 1.51 > +++ dlls/kernel/file.c 5 Apr 2006 05:43:28 -0000 > @@ -1552,7 +1553,9 @@ HANDLE WINAPI FindFirstFileExW( LPCWSTR > OBJECT_ATTRIBUTES attr; > IO_STATUS_BLOCK io; > NTSTATUS status; > + ULONG dos_device; > > + > TRACE("%s %d %p %d %p %lx\n", debugstr_w(filename), level, data, search_op, filter, flags); > > if ((search_op != FindExSearchNameMatch && search_op != FindExSearchLimitToDirectories) > @@ -1575,8 +1578,74 @@ HANDLE WINAPI FindFirstFileExW( LPCWSTR > > if (!mask || !*mask) > { > - SetLastError( ERROR_FILE_NOT_FOUND ); > - goto error; > + if(!mask && (dos_device = RtlIsDosDeviceName_U( filename ))) > + { > + WIN32_FIND_DATAW *d = data; //create file's attribute structure > + > + > + /*LOWORD(dos_device) - quantity of symbols in the DOS device name (NUL, LPT1,...) > + filename + HIWORD(dos_device) - points to the Dos device name's beginning */ > + if (!(info = HeapAlloc( GetProcessHeap(), 0, sizeof(*info)))) > + { > + SetLastError( ERROR_NOT_ENOUGH_MEMORY ); > + goto error; > + } > + > + info->mask.Length = LOWORD(dos_device); /* in bytes, not in WCHAR; as USHORT Length */ > + info->mask.MaximumLength = nt_name.Length + sizeof(WCHAR); > + info->mask.Buffer = RtlAllocateHeap(GetProcessHeap(), 0, info->mask.MaximumLength); > + memcpy( info->mask.Buffer, filename + HIWORD(dos_device)/sizeof(WCHAR), info->mask.Length); > + info->mask.Buffer[info->mask.Length/sizeof(WCHAR)] = 0; /* with '/' */ > + > + nt_name.Length = 4*sizeof(WCHAR) + HIWORD(dos_device); > + nt_name.MaximumLength = nt_name.Length + sizeof(WCHAR); /* + '0' at the end */ > + nt_name.Buffer = RtlAllocateHeap(GetProcessHeap(), 0, nt_name.MaximumLength); > + nt_name.Buffer[0] = '\\'; /* convert to NT' style path */ > + nt_name.Buffer[1] = nt_name.Buffer[2] = '?'; > + nt_name.Buffer[3] = '\\'; > + memcpy( (void *)(nt_name.Buffer + 4), filename, HIWORD(dos_device)); > + nt_name.Buffer[nt_name.Length/sizeof(WCHAR)] = 0; /* with '/' */ > + > + /* check if pftLastAccessTimeath is the root of the drive */ > + info->is_root = FALSE; > + > + attr.Length = sizeof(attr); > + attr.RootDirectory = 0; > + attr.Attributes = OBJ_CASE_INSENSITIVE; > + attr.ObjectName = &nt_name; > + attr.SecurityDescriptor = NULL; > + attr.SecurityQualityOfService = NULL; > + > + /* check if nt_name is existing directory */ > + status = NtOpenFile( &info->handle, GENERIC_READ, &attr, &io, > + FILE_SHARE_READ | FILE_SHARE_WRITE, > + FILE_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT ); > + > + if (status != STATUS_SUCCESS) > + { > + RtlFreeUnicodeString( &info->mask ); > + SetLastError( RtlNtStatusToDosError(status) ); > + goto error; > + } > + > + RtlInitializeCriticalSection( &info->cs ); > + info->path = nt_name; > + info->magic = FIND_FIRST_MAGIC; > + info->data_pos = 0; > + info->data_len = 0; > + info->search_op = search_op; > + > + memset(d, 0, sizeof(*d)); > + d->dwFileAttributes = FILE_ATTRIBUTE_ARCHIVE; > + memcpy( d->cFileName, filename + HIWORD(dos_device)/sizeof(WCHAR), LOWORD(dos_device)); > + > + return (HANDLE)info; > + } > + else > + { > + SetLastError( ERROR_FILE_NOT_FOUND ); > + goto error; > + } > } most of the code here is rather close to the rest of the function, so you should try to factorize the two paths into a single one > > if (!(info = HeapAlloc( GetProcessHeap(), 0, sizeof(*info)))) > @@ -1612,6 +1681,7 @@ HANDLE WINAPI FindFirstFileExW( LPCWSTR > attr.SecurityDescriptor = NULL; > attr.SecurityQualityOfService = NULL; > > + /* check if nt_name is existing directory */ > status = NtOpenFile( &info->handle, GENERIC_READ, &attr, &io, > FILE_SHARE_READ | FILE_SHARE_WRITE, > FILE_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT ); > @@ -1819,6 +1889,14 @@ HANDLE WINAPI FindFirstFileExA( LPCSTR l > FILE_name_WtoA( dataW.cFileName, -1, dataA->cFileName, sizeof(dataA->cFileName) ); > FILE_name_WtoA( dataW.cAlternateFileName, -1, dataA->cAlternateFileName, > sizeof(dataA->cAlternateFileName) ); > +/****************************************************** > +* * > +* In Windows fields dataA->dwReserved0 = 0x003D4830 * > +* and dataA->dwReserved1 = 0x000000CC * > +* But here these fields are not initialized and used * > +* * > +******************************************************/ there's no need for this comment, unless you document what those fields are in real windows > + > return handle; > } -- Eric Pouech

1 0

What version of freetype are we requiring these days
by Bill Medland April 24, 2006

April 24, 2006

I have just noticed that configure is telling me "Warning: Freetype or Fontforge is missing" Why does it think that? (freetype-devel version 2.1.9 is installed) -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

3 4

Re: Sum-up: Re-proposal: web forums
by Sterling Christensen April 24, 2006

April 24, 2006

> > Mailing lists are searchable, but harder than a forum to search. > > Forums let you search by any of text, title, author, date, category, > > Ok, that sounds nice. > > The 'category' thing sounds tricky to implement on top of a mailing > list (as I would like it)... Yes, categories are nice. > > You can't cancel or edit posts. Forum moderators can delete spam > > posts. > > That's just a horrible feature. > As with any kind of censorship it will do nothing but make people > suspect you for deleting legitimate posts. There've been forums like that, but they die quickly. Only forums with trustworthy admins get popular. So that's generally not a problem. > Spam should be removed (or maybe categorized under 'spam') by a spam filter. > And if one does slip through, it will disappear in the noise in no time. > Aren't most forums like about 30.000 pages long? > Would you ever notice anything like a single spam mail? Yes, most people do notice them, because even popular fast moving forums aren't noisy - they lists thread titles instead of posts. It's a lot more concise that way - you don't get bured in posts. For some reason spammers never post in existing threads, they always create new ones. And at every active forum I've seen, their posts always get noticed, reported, and moved or removed.

6 6