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

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