February 2011 - Wine-Devel - list.winehq.org

RE: gdi32: Upper 24 bits of a character range must be same.

by Kusanagi Kouichi

On 2011-02-03 04:11:39 -0800, Greg Geldorp wrote: > Hi, > > I'm sure you've noticed that this change causes some failures on a Simplified > Chinese-language test machine, see > http://test.winehq.org/data/5ae2b0f219cb5aed2bdf32746a57a699a32767a2/xp_wtb… > Can you take a look at that please? > I'm wondering if it wouldn't make more sense to use GetCharABCWidthsW instead > of the Ansi version for this test? > > Thanks, Greg. I guess those failures are caused by font association. Tests succeed on japanese environment. Font association is this bug. http://bugs.winehq.org/show_bug.cgi?id=16325 This link from comment #88 would explain why tests fail. http://blogs.msdn.com/b/michkap/archive/2008/02/29/7945019.aspx

Feb. 3, 2011

RE: gdi32: Upper 24 bits of a character range must be same.

by Greg Geldorp

Hi, I'm sure you've noticed that this change causes some failures on a Simplified Chinese-language test machine, see http://test.winehq.org/data/5ae2b0f219cb5aed2bdf32746a57a699a32767a2/xp_wtb… Can you take a look at that please? I'm wondering if it wouldn't make more sense to use GetCharABCWidthsW instead of the Ansi version for this test? Thanks, Greg.

Feb. 3, 2011

Re: msvcrt: Partially implement type_info::name_internal_method()

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -260,3 +307,24 @@ int CDECL _atoflt( _CRT_FLOAT *value, char *str ) > { > return _atoflt_l( value, str, NULL ); > } > + > +/********************************************************************* > + * ?_name_internal_method(a)type_info@@QBEPBDPAU__type_info_node@@@Z (MSVCR90.@) > + */ > +DEFINE_THISCALL_WRAPPER(MSVCRT_type_info_name_internal_method,8) > +const char * __thiscall MSVCRT_type_info_name_internal_method(type_info * _this, struct __type_info_node *node) > +{ > + /* this is a forward to type_info::name() */ > +#ifdef __i386__ > + static const char *typeinfo_name = "?name(a)type_info@@QBEPBDXZ"; > + void* (WINAPI *p)(void*); > +#else > + static const char typeinfo_name[] = "?name(a)type_info@@QEBAPEBDXZ"; > + void* (__cdecl *p)(void*); > +#endif > + static int once; > + > + if (node && !once++) FIXME("type_info_node parameter ignored\n"); > + p = (void*)GetProcAddress(GetModuleHandleA("msvcrt.dll"), typeinfo_name); > + return call_func1(p, _this); > +} I think it would be better to duplicate the implementation after all. Sorry for misleading you with the GetProcAddress suggestion, I hadn't realized that it would require the thiscall mess. -- Alexandre Julliard julliard(a)winehq.org

Feb. 3, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by Francois Gouget

On Tue, 1 Feb 2011, Juan Lang wrote: [...] > I may be flogging a dead horse here, but I personally am loath to see > another implementation creep in, side by side with the existing one, > that has no guarantee of working any better. As far as I understand it's not going to be another implementation. But you're probably right to warn about having multiple backends; that can be bad too as has been seen with sound. > Worse, even if you succeed in fixing bugs for your Mac customers, the > rest of us don't benefit, as the current implementation still isn't > getting any support. Not true. Anyone using Wine on Mac OS X will benefit by not having to hunt down for a non-standard library to either compile or run Wine. That means Mac users will be more likely to actually have a somewhat functional schannel. Even those who use a packaged Wine will benefit because it means they will no longer either receive an outdated GnuTLS library that contains vulnerabilities with their Wine, or have to hunt one down on their own, or have no schannel support. You say that schannel needs a lot of improvement and you say that we/the community should work on that first. However making schannel perfect will not make the dependency on GnuTLS any more acceptable on Mac OS X. So both need to be done it's only a matter of 'in which order'? Option 1 1) Improve Mac support 2) Improve schannel Drawback is (1) makes (2) much harder but this has not been conclusively proven. Option 2 1) Improve schannel until it's 'good enough' 2) Improve Mac support This means _most_ Mac users won't get any schannel support for a long time. And in terms of development it means a big refactoring phase near the end which may well be pretty disruptive too (hopefully it wouldn't be as bad as the display backend or DIB engine refactoring). Not that I care about schannel anyway. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ In a world without fences who needs Gates?

Feb. 3, 2011

Re: Try to Implement my first Stub function - AbortPrinter().

by Nikolay Sivov

On 2/3/2011 13:51, Loïc Maury wrote: > Hello, > > I try to implement my first stub function - *AbortPrinter()*. > But before to make a patch, I need your advice. > > For what I understood, AbortPrinter(), remove the document > spool file for a printer, created by StartDocPrinter(), who indicate > that a document was spooled. > > I saw that the API printer functions are in dlls/winspool.drv/info.c > > I understood that there are 4 structures used, *opened_printer_t* for > manage a printer, > *jobqueue_t* for a list of job for a printer, *started_doc_t* who > manage a document, > and *job_t* for manage a job. > > I am on Mac Os 10.6, with CUPS. > > Here is the code, what do you think ? Patch needs to be a diff, not a copy of a call. Some useful links http://wiki.winehq.org/GitWine, http://wiki.winehq.org/SubmittingPatches. > BOOL WINAPI AbortPrinter(HANDLE hPrinter) > { > PRINTER_INFO_5W *pi5 = NULL; > BOOL ret = FALSE; > opened_printer_t *printer; > struct list *cursor, *cursor2; > job_t *job = 0; No need to init 'job' it seems. > DWORD jobDocId; > DWORD needed; > LPWSTR portname; > > #if defined(__APPLE__) Why it's Mac specific? > > EnterCriticalSection(&printer_handles_cs); > > printer = get_opened_printer(hPrinter); > > if(!printer) > { > ERR("The handle for the printer is invalid.\n"); > SetLastError(ERROR_INVALID_HANDLE); If you set last error you should add a test for it. > goto end; > } > > TRACE("(%s, %s, %p, %d, %d)\n",debugstr_w(printer->name) > ,debugstr_w(printer->printername) > ,printer->backend_printer > ,printer->queue->ref > ,list_count(&printer->queue->jobs)); > > /* No jobs to manage. */ > if(list_count(&printer->queue->jobs) == 0) > { > ERR("No job in the list.\n"); It's not an error to have no jobs. > SetLastError(ERROR_SPL_NO_STARTDOC); > goto end; > } > > if(printer->doc) { > TRACE("Document inside for job id : %d\n", printer->doc->job_id); > jobDocId = printer->doc->job_id; > } > else { > ERR("No document.\n"); > SetLastError(ERROR_SPL_NO_STARTDOC); > goto end; > } > > /* For each jobs, get the job document in the double linked list */ > LIST_FOR_EACH_SAFE(cursor, cursor2, &printer->queue->jobs) > { > /* Take a job. */ > job = LIST_ENTRY(cursor, job_t, entry); > > TRACE("(job id : %d, filename : %s, portname : %s, document > title : %s, printer name %s)\n",job->job_id > > ,debugstr_w(job->filename) > > ,debugstr_w(job->portname) > > ,debugstr_w(job->document_title) > > ,debugstr_w(job->printer_name)); > if(jobDocId == job->job_id) > { > TRACE("(hf : %p, job id : %d)\n",printer->doc->hf > ,printer->doc->job_id); > > /* Get portname. */ > if (!job->portname) > { > GetPrinterW(hPrinter, 5, NULL, 0, &needed); > pi5 = HeapAlloc(GetProcessHeap(), 0, needed); > GetPrinterW(hPrinter, 5, (LPBYTE)pi5, needed, &needed); > portname = pi5->pPortName; > } > > TRACE("portname : %s\n", debugstr_w(portname)); > > /* Cups Port */ > if(!strncmpW(portname, CUPS_Port, strlenW(CUPS_Port))) > { > TRACE("Remove job from the list.\n"); > list_remove(cursor); > CloseHandle(printer->doc->hf); > DeleteFileW(job->filename); > HeapFree(GetProcessHeap(), 0, job->document_title); > HeapFree(GetProcessHeap(), 0, job->printer_name); > HeapFree(GetProcessHeap(), 0, job->portname); > HeapFree(GetProcessHeap(), 0, job->filename); > HeapFree(GetProcessHeap(), 0, job->devmode); > HeapFree(GetProcessHeap(), 0, job); > job = 0; What is it for? > ret = TRUE; > > if(pi5) > HeapFree(GetProcessHeap(), 0, pi5); No need to check point here. > } > else > FIXME("only CUPS for now.\n"); > } > } > > end: > LeaveCriticalSection(&printer_handles_cs); > > TRACE("return %d\n", ret); > return ret; > > #else > TRACE("Only CUPS for Mac Os is managed for now.\n"); > return FALSE; > #endif This should stay as FIXME obviously. > } > > Merci > > Loïc > > >

Feb. 3, 2011

Try to Implement my first Stub function - AbortPrinter().

by Loïc Maury

Hello, I try to implement my first stub function - *AbortPrinter()*. But before to make a patch, I need your advice. For what I understood, AbortPrinter(), remove the document spool file for a printer, created by StartDocPrinter(), who indicate that a document was spooled. I saw that the API printer functions are in dlls/winspool.drv/info.c I understood that there are 4 structures used, *opened_printer_t* for manage a printer, *jobqueue_t* for a list of job for a printer, *started_doc_t* who manage a document, and *job_t* for manage a job. I am on Mac Os 10.6, with CUPS. Here is the code, what do you think ? BOOL WINAPI AbortPrinter(HANDLE hPrinter) { PRINTER_INFO_5W *pi5 = NULL; BOOL ret = FALSE; opened_printer_t *printer; struct list *cursor, *cursor2; job_t *job = 0; DWORD jobDocId; DWORD needed; LPWSTR portname; #if defined(__APPLE__) EnterCriticalSection(&printer_handles_cs); printer = get_opened_printer(hPrinter); if(!printer) { ERR("The handle for the printer is invalid.\n"); SetLastError(ERROR_INVALID_HANDLE); goto end; } TRACE("(%s, %s, %p, %d, %d)\n",debugstr_w(printer->name) ,debugstr_w(printer->printername) ,printer->backend_printer ,printer->queue->ref ,list_count(&printer->queue->jobs)); /* No jobs to manage. */ if(list_count(&printer->queue->jobs) == 0) { ERR("No job in the list.\n"); SetLastError(ERROR_SPL_NO_STARTDOC); goto end; } if(printer->doc) { TRACE("Document inside for job id : %d\n", printer->doc->job_id); jobDocId = printer->doc->job_id; } else { ERR("No document.\n"); SetLastError(ERROR_SPL_NO_STARTDOC); goto end; } /* For each jobs, get the job document in the double linked list */ LIST_FOR_EACH_SAFE(cursor, cursor2, &printer->queue->jobs) { /* Take a job. */ job = LIST_ENTRY(cursor, job_t, entry); TRACE("(job id : %d, filename : %s, portname : %s, document title : %s, printer name %s)\n",job->job_id ,debugstr_w(job->filename) ,debugstr_w(job->portname) ,debugstr_w(job->document_title) ,debugstr_w(job->printer_name)); if(jobDocId == job->job_id) { TRACE("(hf : %p, job id : %d)\n",printer->doc->hf ,printer->doc->job_id); /* Get portname. */ if (!job->portname) { GetPrinterW(hPrinter, 5, NULL, 0, &needed); pi5 = HeapAlloc(GetProcessHeap(), 0, needed); GetPrinterW(hPrinter, 5, (LPBYTE)pi5, needed, &needed); portname = pi5->pPortName; } TRACE("portname : %s\n", debugstr_w(portname)); /* Cups Port */ if(!strncmpW(portname, CUPS_Port, strlenW(CUPS_Port))) { TRACE("Remove job from the list.\n"); list_remove(cursor); CloseHandle(printer->doc->hf); DeleteFileW(job->filename); HeapFree(GetProcessHeap(), 0, job->document_title); HeapFree(GetProcessHeap(), 0, job->printer_name); HeapFree(GetProcessHeap(), 0, job->portname); HeapFree(GetProcessHeap(), 0, job->filename); HeapFree(GetProcessHeap(), 0, job->devmode); HeapFree(GetProcessHeap(), 0, job); job = 0; ret = TRUE; if(pi5) HeapFree(GetProcessHeap(), 0, pi5); } else FIXME("only CUPS for now.\n"); } } end: LeaveCriticalSection(&printer_handles_cs); TRACE("return %d\n", ret); return ret; #else TRACE("Only CUPS for Mac Os is managed for now.\n"); return FALSE; #endif } Merci Loïc

Feb. 3, 2011

Re: [PATCH 2/5] winex11.drv: Complain a bit about missing s3tc support.

by Tobias Jakobi

> I'm not entirely sure on how to do this properly. Making it an ERR > would be too loud for applications that never use s3tc textures, as a > WARN it's never going to be seen unless you look at the debug channel. > Printing a message in wined3d in CreateSurface() would probably work, > but the resulting check would end up being pretty ugly because we'd > have to check 5 different formats. You can't do much more than a WARN > for a generic check either, because some formats may be legitimately > missing / unimplemented. Note that the situation with floating point > formats isn't much better. > I'd say go with a WARN then. At least we've something then. The current situation is just not acceptable, since a lot of games ship precompressed textures in DDS format and just expect them to work. If this works for native D3D impl then it should work here too. Or at least we should warn the user that something might go wrong. Maybe we should also add some entry to the wiki ('Setting up open-source drivers for wine') and mention the current issues (s3tc support in general, complete lack of s3tc support in r600g, etc.) Greets, Tobias

Feb. 3, 2011

Re: Wine FAQ edits

by Vitaliy Margolen

On 02/02/2011 09:52 PM, Albert Lee wrote: > I meant 'cd' is the command preceding this one in the block this is a > part of, if you look at the context. Then you should remove that cd instead. Starting instructions from "go to your home directory" just to jump somewhere else doesn't make much sense. > It's exec(2)'ed so it doesn't matter what the program is. Basically run in a shell. So you need an extra wrapper (env) why? > It works perfectly fine, thank you. It's not parsed by Wine and none > of the embedded characters are metacharacters for the registry. That's the > reason for explicitly calling /bin/sh -c. Don't write programs inside registry, especially involving multiple expansions and output redirection. That's what the shell is for. Keep it there as a simple 2 line script. Vitaliy.

Feb. 3, 2011

Re: Wine FAQ edits

by Albert Lee

On Wed, Feb 2, 2011 at 1:52 AM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > On 02/01/2011 09:47 PM, Albert Lee wrote: >> >> On Sat, Jan 29, 2011 at 4:36 PM, Vitaliy<vitaliy(a)kievinfo.com> wrote: >>>> >>>> -cd ~/.wine/drive_c/Program\ Files >>>> +cd .wine/drive_c/Program\ Files >>> >>> This will break if current directory is not $HOME. >>> >> >> 'cd' immediately precedes this. > > That still doesn't make the command valid. It won't work from any directory, > that's the point. I meant 'cd' is the command preceding this one in the block this is a part of, if you look at the context. This is explaining how to navigate to the application's directory and run Wine. I wrote most of the original text for this section, FYI. > >>>> -/bin/sh -c glxgears >>>> +/usr/bin/env glxgears >>> >>> What advantage does "env" has over full featured shell? This is >>> unnecessary. >> >> Why do you need a full shell to run a single external program? It >> complicates e.g. argument passing if you used this as a template. > > Why do you don't want a full featured shell? What of that program is a shell > script? It's exec(2)'ed so it doesn't matter what the program is. That's the point of the interpreter specification. > >>>> -@="/bin/sh run_linx_program acroread \"%1\"" >>>> +@="/bin/sh -c \"acroread `wine winepath -u '%1'`\"" >>> >>> Have you actually tested this? This won't work for paths with spaces. If >>> it >>> will work at all. >>> >> >> Not with spaces, I'll fix this as well. > > You still failed to test if it works. What "supposed to work" in shell > doesn't mean it works in Wine's process exec. So please test your > suggestions first. With Wine. And don't write shell scripts inside registry. > That won't work or do what you think it "should". It works perfectly fine, thank you. It's not parsed by Wine and none of the embedded characters are metacharacters for the registry. That's the reason for explicitly calling /bin/sh -c. -Albert

Feb. 3, 2011

Re: Wine FAQ edits

by Vitaliy Margolen

On 02/02/2011 08:10 AM, Albert Lee wrote: > I notice you reverted the changes after I addressed these issues, care > to explain why? See my response from yesterday. Vitaliy.

Feb. 3, 2011

Re: [PATCH 2/5] winex11.drv: Complain a bit about missing s3tc support.

by Henri Verbeet

On 3 February 2011 01:00, Tobias Jakobi <liquid.acid(a)gmx.net> wrote: > *bumping* > > This patch never went into master, although it's _very_ important. Wine > users see a lot of D3D problems (mostly missing textures) since mesa drivers > don't support s3tc "out-of-the-box" (libtxc_dxtn needs to be available). > This leads to a lot of 'false' bug reports, which are in fact driver issues. > > Requesting to finally push this to master. > I'm not entirely sure on how to do this properly. Making it an ERR would be too loud for applications that never use s3tc textures, as a WARN it's never going to be seen unless you look at the debug channel. Printing a message in wined3d in CreateSurface() would probably work, but the resulting check would end up being pretty ugly because we'd have to check 5 different formats. You can't do much more than a WARN for a generic check either, because some formats may be legitimately missing / unimplemented. Note that the situation with floating point formats isn't much better.

Feb. 3, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by Ken Thomases

On Feb 2, 2011, at 11:38 AM, Juan Lang wrote: > That's fine. You asked for feedback on your general approach, and > described it as a proof of concept. I gave you feedback on it as > such. I appreciate your feedback. Although, in truth, I was asking more about how to do it (wether to separate the two implementations into separate modules, etc.) rather than whether. :) I described the patch as a proof of concept to emphasize that it wasn't in the final form, but a snapshot of a particular point in my development as I got it working the first time. Anyway, thanks. I guess I'll try submitting actual patches and see how far that gets. :) Cheers, Ken

Feb. 2, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by Alexandre Julliard

Juan Lang <juan.lang(a)gmail.com> writes: > Since that thread, where I stated that new code based on OpenSSL > wasn't likely to get accepted, an OpenSSL dependency was added to > winhttp. Apparently I was mistaken. It's not really new code, winhttp is just a copy of the wininet code. The plan is still to get rid of OpenSSL. -- Alexandre Julliard julliard(a)winehq.org

Feb. 2, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by Juan Lang

Hi Damjan, > OpenSSL seems like a bad idea. It has poor binary compatibility and > problematic FIPS 140 certification, and Fedora is dropping it in favour of > NSS: > http://fedoraproject.org/wiki/FedoraCryptoConsolidation > http://fedoraproject.org/wiki/CryptoConsolidationEval Maybe, but OpenSSL is a requirement for wininet and winhttp right now. For Fedora's proposed crypto consolidation, they're also proposing building a compatibility layer for OpenSSL on top of NSS, so it's possible that Wine's uses of OpenSSL could use these, too. But this is essentially hypothetical. As Henri noted, wininet and winhttp should be layered on top of schannel. This is a requirement to fix a couple of bugs in at least wininet (though I'm less sure about winhttp). It has the added advantage of consolidating an SSL implementation in Wine into one place. Then, if platform-dependent SSL libraries are required, either to support Fedora and other Linux distributions that have divided opinions about SSL implementations, or to use Mac's Secure Transport libraries on that platform, they would only have to be done in one place. > OpenSSL isn't part of the LSB (while NSS is), so if we ever want to make a > Wine LSB package, it might be a good idea to get OpenSSL out of Wine > entirely. See also the August 2008 wine-devel thread about this: > http://www.winehq.org/pipermail/wine-devel/2008-August/068575.html Since that thread, where I stated that new code based on OpenSSL wasn't likely to get accepted, an OpenSSL dependency was added to winhttp. Apparently I was mistaken. Thanks, --Juan

Feb. 2, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by Juan Lang

>> I don't see how this >> helps CodeWeavers, either, other than reducing installation >> complexity. > > Well, Outlook didn't used to be able to connect to Gmail IMAP in our Mac product and now it does. As I said, this only reduces installation complexity: I assume that, had you installed GnuTLS, it would have as well. If not, then there's a bug in the GnuTLS implementation. > Everybody, whether volunteer or commercial, devotes development time to Wine to "scratch their itch", however they define that. For us, it's largely to meet customer needs. This work did that. The work you describe doesn't, particularly. It may, someday. It is quite a bit more likely to now because our Mac product has schannel support, so it will get exercised by many more of our customers, and they'll find the problems with it. (Or, if few real-world applications encounter limitations with schannel as it stands, then schannel is de facto fine as-is.) That's fine. You asked for feedback on your general approach, and described it as a proof of concept. I gave you feedback on it as such. If you wish to treat it as a fait accompli, then I'm not the one who can give input anyway: only Alexandre is. In any event, I've said my piece: I don't like this approach, and I think there are better ones. I'll repeat it just so it's in one place: I think tests would be the most valuable improvement to schannel. If a Mac friendlier implementation is desired, I'll note that OpenSSL may work as well on the Mac, with the added advantage that it's also available on Linux(*), and is also already a requirement for wininet and winhttp on all platforms. (*) Damjan raised an objection to OpenSSL, which I'll address separately. Regards, --Juan

Feb. 2, 2011

Re: wined3d: Update clip planes when switching to/from offscreen rendering.

by Matteo Bruni

2011/1/31 Stefan Dösinger <stefandoesinger(a)gmx.at>: > Am 31.01.2011 um 17:08 schrieb Matteo Bruni: >> The attached patch should follow your idea, does it look right? FWIW, >> I can't see any 1-pixel offset in The Sims 3 with this patch. Yes, I >> know that's not how it should be tested... > Looks OK on first sight. Does it work as well? > It seems to work. :) > I can't think of any game where you could see a half pixel issue wrt clipplanes. Maybe the d3d7 clipping example can shows something, but I think to be sure you'd have to write a test. > Is the test I attached a good way to check for that? I could send this test to wine-patches too (or a fixed version if it happens to be broken).

Feb. 2, 2011

Re: Wine FAQ edits

by Rosanne DiMesio

On Wed, 2 Feb 2011 10:09:16 -0500 Albert Lee <trisk(a)forkgnu.org> wrote: > The Open Group even more strongly objects to the phrase "Unix-like". > They also state explicitly on their website that Linux is not Unix. http://www.unix.org/what_is_unix/flavors_of_unix.html Ozan's suggestion of "Posix-compatible" is more accurate. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Feb. 2, 2011

Re: ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces

by Qian Hong

On Wed, Feb 2, 2011 at 11:08 PM, Dan Kegel <dank(a)kegel.com> wrote: > Qian wrote: >>1. If a function is implemented in wine dll as a stup, then usually >>this function won't cause crash, >>and the wine debug will output "fix:me ...stup" rather then >>"Unimplemented function", is it right? > > I think "stub" is somewhat ambiguous, it can mean either > something without an implementation, or something > with a very minimal implementation. > But yes, if something is listed in dlls/*/*.spec as a stub, > you get 'Unimplemented function', and if something is listed in > grep FIXME.*stub dlls/*/*.c > as a stub, you get > "fixme: ... stub". > Thanks very much! I think now I understand. Thanks Ricardo as well. Grateful to you all! >>2. If a function is listed in the Wine API guide, >>http://source.winehq.org/WineAPI/ , and marked as stup, >>then this function must be implemented as a stup in wine source code, >>is it right? > > The Wine API guide is not a very reliable guide, it might be out > of date. Better to just look in the source code. > - Dan > -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

Feb. 2, 2011

Re: Wine FAQ edits

by Albert Lee

I notice you reverted the changes after I addressed these issues, care to explain why? On Tue, Feb 1, 2011 at 11:47 PM, Albert Lee <trisk(a)forkgnu.org> wrote: > On Sat, Jan 29, 2011 at 4:36 PM, Vitaliy <vitaliy(a)kievinfo.com> wrote: >> On 01/29/2011 12:21 PM, Dan Kegel wrote: >>> >>> Hi Albert, >>> http://wiki.winehq.org/FAQ?action=diff&rev2=384&rev1=383 looks >>> like it was a pretty big edit. >>> >>> Try smaller ones, and try to do just one kind of change per edit. >> >> That, and the fact that some changes where questionable, and broken: >> >>> -cd ~/.wine/drive_c/Program\ Files >>> +cd .wine/drive_c/Program\ Files >> >> This will break if current directory is not $HOME. >> > > 'cd' immediately precedes this. > >>> - You can also use double quotes, but you need two backslashes instead of >>> one: >>> - >>> -{{{ >>> -wine start "C:\\Games\\Tron\\tron.exe" >>> -}}} >> >> Backslashes still have special meaning inside double quotes. So they should >> be escaped. > > Yes, I'll fix this. > >> >>> -/bin/sh -c glxgears >>> +/usr/bin/env glxgears >> >> What advantage does "env" has over full featured shell? This is unnecessary. > > Why do you need a full shell to run a single external program? It > complicates e.g. argument passing if you used this as a template. > >> >>> -@="/bin/sh run_linx_program acroread \"%1\"" >>> +@="/bin/sh -c \"acroread `wine winepath -u '%1'`\"" >> >> Have you actually tested this? This won't work for paths with spaces. If it >> will work at all. >> > > Not with spaces, I'll fix this as well. > > -Albert >

Feb. 2, 2011

Re: Wine FAQ edits

by Albert Lee

On Wed, Feb 2, 2011 at 8:03 AM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote: > On Sat, 29 Jan 2011 13:18:40 -0500 > Albert Lee <trisk(a)forkgnu.org> wrote: > >> >> I notice you have reverted my edits to the FAQ on the wiki ( >> http://wiki.winehq.org/FAQ?action=info ). As I was trying to clarify >> the shell metacharacter information and operating system/platform >> support, and add new file association instructions, I would like to >> know why this happened and what changes should be done. >> > Albert, > > Besides the problems Vitaliy has pointed out with your edits, your repeated attempts to substitute "Unix" for "Linux" in multiple places is flat-out wrong. "Unix" is a trademarked name, with a specific meaning. It is not a generic synonym for Linux, BSD, etc. and should not be used as such. > While "UNIX" is a trademark for Open Group certification, it has long existed as a generic term in engineering and academia to refer to the to set of standards that define systems with this heritage, and where these are being referred to it is much better than listing the implementations (and Wine does run on "UNIX" certified platforms). The Open Group even more strongly objects to the phrase "Unix-like". -Albert

Feb. 2, 2011

re: ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces

by Dan Kegel

Qian wrote: >1. If a function is implemented in wine dll as a stup, then usually >this function won't cause crash, >and the wine debug will output "fix:me ...stup" rather then >"Unimplemented function", is it right? I think "stub" is somewhat ambiguous, it can mean either something without an implementation, or something with a very minimal implementation. But yes, if something is listed in dlls/*/*.spec as a stub, you get 'Unimplemented function', and if something is listed in grep FIXME.*stub dlls/*/*.c as a stub, you get "fixme: ... stub". >2. If a function is listed in the Wine API guide, >http://source.winehq.org/WineAPI/ , and marked as stup, >then this function must be implemented as a stup in wine source code, >is it right? The Wine API guide is not a very reliable guide, it might be out of date. Better to just look in the source code. - Dan

Feb. 2, 2011

Re: RFC: Adding Mac support to secur32/schannel.c

by Ken Thomases

On Feb 1, 2011, at 10:19 AM, Juan Lang wrote: > I may be flogging a dead horse here, but I personally am loath to see > another implementation creep in, side by side with the existing one, > that has no guarantee of working any better. Well, it won't work any better, just as well as. > I don't see how this > helps CodeWeavers, either, other than reducing installation > complexity. Well, Outlook didn't used to be able to connect to Gmail IMAP in our Mac product and now it does. > If there are bugs in the new implementation, and I expect > there will be, you'll still have a large support load. Worse, even if > you succeed in fixing bugs for your Mac customers, the rest of us > don't benefit, as the current implementation still isn't getting any > support. That's not true. First, if there are bugs that affect our products, it will likely affect both our Linux and Mac products, and we'd fix it in both. But more to the point, as I've said before, the schan_imp_* stuff is a very, very thin wrapper around the platform library (Secure Transport on the Mac and GnuTLS elsewhere). It is quite unlikely that the sorts of bugs you're concerned about -- in the logic of schannel -- would be in the platform-specific code. They'd be in the code that's shared. So, the fixes would be shared, too. > If there are development resources available to work on > schannel, why not put them into something that benefits the project as > a whole? Everybody, whether volunteer or commercial, devotes development time to Wine to "scratch their itch", however they define that. For us, it's largely to meet customer needs. This work did that. The work you describe doesn't, particularly. It may, someday. It is quite a bit more likely to now because our Mac product has schannel support, so it will get exercised by many more of our customers, and they'll find the problems with it. (Or, if few real-world applications encounter limitations with schannel as it stands, then schannel is de facto fine as-is.) Lots of work contributed to Wine doesn't benefit everybody, but only improves things for one particular use case. It's still an improvement to the project as a whole, even if most don't receive the benefit. Regards, Ken

Feb. 2, 2011

Re: Wine FAQ edits

by Rosanne DiMesio

On Sat, 29 Jan 2011 13:18:40 -0500 Albert Lee <trisk(a)forkgnu.org> wrote: > > I notice you have reverted my edits to the FAQ on the wiki ( > http://wiki.winehq.org/FAQ?action=info ). As I was trying to clarify > the shell metacharacter information and operating system/platform > support, and add new file association instructions, I would like to > know why this happened and what changes should be done. > Albert, Besides the problems Vitaliy has pointed out with your edits, your repeated attempts to substitute "Unix" for "Linux" in multiple places is flat-out wrong. "Unix" is a trademarked name, with a specific meaning. It is not a generic synonym for Linux, BSD, etc. and should not be used as such. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Feb. 2, 2011

Re: ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces

by Ricardo Filipe

2011/2/2 Qian Hong <fracting(a)gmail.com> > Dear Nikolay and James, > > On Sun, Jan 30, 2011 at 11:09 PM, James McKenzie > <jjmckenzie51(a)earthlink.net> wrote: > > Qian: > > > > I would like to echo Nikolay's comment and add one more: > > > > Please search through the Bug Reports before submitting a new one. > > I really feel very sorry, I apologize for posting such issues the > wrong place and making noise. Thank you for your reminder and your > nice work on wine. > I have searched the Bugzilla with ntoskrnl.exe as keyword carefully, > it seems that none of the current bugs mentions unimplemented function > ntoskrnl.exe.IoGetDeviceInterfaces, so I report a new issue here: > http://bugs.winehq.org/show_bug.cgi?id=25964 > Wish it not a duplicate. > > > > > You might receive more assistance on the Wine User list as well. Most of > > the developers lurk there. > > > > I'll post such mails on the Wine User list from now on. > However, may I modestly consults below questions here: > > 1. If a function is implemented in wine dll as a stup, then usually > this function won't cause crash, > and the wine debug will output "fix:me ...stup" rather then > "Unimplemented function", is it right? > 2. If a function is listed in the Wine API guide, > http://source.winehq.org/WineAPI/ , and marked as stup, > then this function must be implemented as a stup in wine source code, > is it right? > > I've read http://wiki.winehq.org/DebugChannels and > http://wiki.winehq.org/Developers-Hints, > but I still have some confusion. > > > Thanks a lot! > > > > Thank you. > > > > > > > -- > Regards, > Qian Hong > - > Sent from Ubuntu > http://www.ubuntu.com/ > > > Yes, a stub is a first step to implement a function. Sometimes a stub is enough for the application to proceed. WineAPI is parsed from wine code, so if it says "stub" in the spec file of that dll it means there is no implementation yet, and a stub can be produced.

Feb. 2, 2011

Re: ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces

by Qian Hong

Dear Nikolay and James, On Sun, Jan 30, 2011 at 11:09 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > Qian: > > I would like to echo Nikolay's comment and add one more: > > Please search through the Bug Reports before submitting a new one. I really feel very sorry, I apologize for posting such issues the wrong place and making noise. Thank you for your reminder and your nice work on wine. I have searched the Bugzilla with ntoskrnl.exe as keyword carefully, it seems that none of the current bugs mentions unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, so I report a new issue here: http://bugs.winehq.org/show_bug.cgi?id=25964 Wish it not a duplicate. > > You might receive more assistance on the Wine User list as well. Most of > the developers lurk there. > I'll post such mails on the Wine User list from now on. However, may I modestly consults below questions here: 1. If a function is implemented in wine dll as a stup, then usually this function won't cause crash, and the wine debug will output "fix:me ...stup" rather then "Unimplemented function", is it right? 2. If a function is listed in the Wine API guide, http://source.winehq.org/WineAPI/ , and marked as stup, then this function must be implemented as a stup in wine source code, is it right? I've read http://wiki.winehq.org/DebugChannels and http://wiki.winehq.org/Developers-Hints, but I still have some confusion. Thanks a lot! > Thank you. > -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

Feb. 2, 2011