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

localspl.dll: Implementation-Question
by Detlef Riekenberg Aug. 9, 2006

Aug. 9, 2006

Am Sonntag, den 30.07.2006, 21:41 +0200 schrieb Detlef Riekenberg: > Printmonitors need spoolss.dll,EnumPortsW > > On windows, all work is done in spoolss.dll and winspool.drv is just the > Forwarder (RPC). > We avoid the need for loading spoolss.dll in every App by > doing the work in winspool.drv and use spoolss.dll as relay. > > > Changelog: > - spoolss: add EnumPortsW (by calling winspool.drv) > The Codebase in "dlls/winspool.drv/info.c" get really large and the actual Code-Path is: "winspool.drv -> CUPS/LPR" (with help from GDI). A possible place to split the Code is at the Printmonitor-Level. The Printmonitor for the Standard "Local Ports" in Windows (COM*:, LPT*:, FILE:, Windows-File) was in "localmon.dll" and merged into "localspl.dll" with w2k. On IRC, Alexandre already accepted to handle Wine-Specific Ports ( CUPS:*, LPR:*, Pipe to a unix_app, /unix-File ) together with the Standard Window-Ports in a single Printmonitor: "localspl.dll" The Requirement, that updating the System-Printers in wine must work automatic, need some Attention, when the related code (LoadSystemPrinters) move from "winspool.drv" to "localspl.dll": 1) Changing the Code-Path to "winspool.drv -> localspl.dll -> CUPS/LPR" and using the same Memory-Functions for "localspl.dll" as done in Windows (the Memory-Related Exports from "spoolss.dll"), give us a circular dependency, when we load and call "winspool.drv" from "spoolss.dll". For this reason, using HeapAlloc(GetProcessHeap(), ...) and Friends from "kernel32.dll" is a Possible way to go for "localspl.dll". 2) To let Printing in Wine work as similar as possible as Printing is done in Windows, (but without RPC and without the Spooler-Service) we can change the Code-Path to "winspool.drv -> spoolss.dll -> localspl.dll -> CUPS/LPR" and use the Exports from "spoolss.dll". Since we need the Memory-Exports from "spoolss.dll" also for other Printmonitors and many Names/Prototypes of the other "spoolss.dll" - Exports are Equal to the Functions in "winspool.drv", I prefer Solution "2". (Wine as an EMF-Printing-Backend for samba is only Possible with 2) As a Reference, what windows does, is: winspool.drv --(RPC)--> spoolsv.exe(Spooler Service) --(WINAPI)--> spoolss.dll -> localspl.dll -> Driver for LPT*: / COM*: Any comments please. Thanks -- By By ... ... Detlef

1 0

Re: This patch should fix bug 4863 - Icons in Notes Workspace
by Augusto Arcoverde da Rocha Aug. 9, 2006

Aug. 9, 2006

Hi all, A little time ago I have sent this patch and now I'm asking to the Wine devel community about the correctness of that code. May be a fix for "Icons in Notes" bug would be incorporated in the next Wine release with some peer-review efforts. Regards, Augusto Arcoverde da Rocha On 7/21/06, Augusto Arcoverde da Rocha <agarobr.listas(a)gmail.com> wrote: > Description: > This patch should fix bug 4863 - Icons in Notes Workspace. > > ChangeLog: > Making SetDIBits function compliant with MSDN documentation by > ignoring the device context parameter if DIB parameter is informed as > having a palette (DIB_PAL_COLORS). > > References: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bitmap… > > Author: > Augusto Arcoverde da Rocha <agarobr\at\yahoo.com.br> > > Notes: > Since I wasn't successful learning more about internal representation > of DIB structure, I couldn't make the apropriated test units for this > fix, sorry. > > >

4 4

Re: version/tests: Write-strings warnings fix
by James Hawkins Aug. 9, 2006

Aug. 9, 2006

On 8/9/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > Please note: in install.c, I have preserved a distinction between "regedit" > and "regedit.exe" that was in the original code. If this distinction is > accidental, please inform me, via wine-devel, and I shall send a revised > version of this patch. > ... > > @@ -34,6 +34,9 @@ > char filename[MAX_PATH]; > char outBuf[MAX_PATH]; > char windir[MAX_PATH]; > + static CHAR empty[] = "", > + regedit_a[] = "regedit", > + regedit_b[] = "regedit.exe"; > > memset(appdir, 0, MAX_PATH); > memset(windir, 0, MAX_PATH); > Seems like regedit and regedit_exe might be better names than regedit_a/b. -- James Hawkins

2 1

Re: WineD3D: draw buffers support (patch 2)
by Roderick Colenbrander Aug. 9, 2006

Aug. 9, 2006

This is a slighly updated version of the patch. The code is the same but I changed the comment a little as suggested by Henri as the part about SM3 was wrong. Roderick > Hi, > > This is a second draw buffers / gl_FragColor patch and it depends on the > other patch which was sent earlier today. The previous patch added draw > buffers support and fixed a gl_FragData bug. This patch fixes another case > where we incorrectly use gl_FragData. > > Regards, > Roderick Colenbrander -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

1 0

wine
by XIAOJING XIN Aug. 9, 2006

Aug. 9, 2006

hi how are you? i am one of wine users , it is a very amazing software i like it very much , and i have a problem here , does wine support other language? i use it to run one of foreign software which is Chinese, but , the wine software can not display the language, so what can i do now , does it only support English software? regard thank you very much

5 6

[FreeBSD] locating wine at 0x20000000
by Tijl Coosemans Aug. 9, 2006

Aug. 9, 2006

Hello all, For the past week or so I've been getting to know Wine and trying to improve/fix the FreeBSD version. I've progressed somewhat since then, though there are still quite a few open issues. One of the problems on FreeBSD is that Wine is loaded at 0x7bf00000. FreeBSD's mmap preserves some space for the data segment (about 512Mb by default) and every future call to mmap with NULL for the addr argument maps memory after that. This is the reason that win98 mode doesn't work, since the shared heap at 0x80000000 isn't available and everything that gets dlopen'ed for instance is located beyond the 2G limit which some programs may not like. So I was thinking of moving Wine to 0x20000000. That would be the easiest solution by far, but, are there any potential problems with that?

2 7

Re: [2/2] WINED3D: Fix D3DCOLOR swizzling in shaders.
by Christoph Frick Aug. 9, 2006

Aug. 9, 2006

On Sat, Aug 05, 2006 at 06:15:42PM +0200, H. Verbeet wrote: > This patch fixes those issues by looking at the data types in the > vertex declaration the shader will be used with. To be able to do > that, we have to wait with compiling the shader until the shader is > first used and we have a vertex declaration. I am not sure, if exactly *this* patch fixes the problem - but i assume so: the colors of the cars and lights in Live For Speed are not fixed also. thanks for that! -- cu

1 0

Re: wineconsole: command line option output / default user backend
by Alexandre Julliard Aug. 9, 2006

Aug. 9, 2006

Ekkehard Morgenstern <ekkehard.morgenstern(a)onlinehome.de> writes: > This small patch provides command line option output, a "--help" option > and a default user backend ("--backend=user" is default) to "wineconsole". Your mailer wrapped the patch, please resend it. Also please send separate changes as separate patches, and try to follow the coding conventions of the surrounding code. -- Alexandre Julliard julliard(a)winehq.org

6 14

widl: Error on simple idl file
by Elrond Aug. 9, 2006

Aug. 9, 2006

Hi, The attached idl file gives an error when used with widl -DUSE_TYPEDEF simple.idl I doubt, that it is a syntax error, since adding "-h" creates the header, using "-c" gives the error. The error is: error: Unsupported member type 0x0 Elrond

1 0

Re: ntdll: make shared user data access work
by Alexandre Julliard Aug. 9, 2006

Aug. 9, 2006

Robert Reif <reif(a)earthlink.net> writes: > diff -p -u -r1.66 thread.c > --- dlls/ntdll/thread.c 26 Jul 2006 14:01:20 -0000 1.66 > +++ dlls/ntdll/thread.c 6 Aug 2006 01:15:43 -0000 > @@ -215,7 +215,7 @@ HANDLE thread_init(void) > > addr = (void *)0x7ffe0000; > size = 0x10000; > - NtAllocateVirtualMemory( NtCurrentProcess(), &addr, 0, &size, MEM_RESERVE, PAGE_READONLY ); > + NtAllocateVirtualMemory( NtCurrentProcess(), &addr, 0, &size, MEM_RESERVE | MEM_COMMIT, PAGE_READONLY); This code is only intended to reserve the space at startup. We need to initialize it properly later on before making it accessible. -- Alexandre Julliard julliard(a)winehq.org

2 2