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

Re: Updated cebit presentation. Looking for ideas...

by Dan Kegel

On Sun, Feb 15, 2009 at 1:26 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote: > Btw, I have run my last 3 Wine presentations in > OpenOffice_org 2.4 for Win32. > > Did not give much crowd "ooooh" effect though. I guess I'm not trying to impress, I'm trying to reassure. So maybe doing it in MS Office 2003 or 2007 in wine or crossover would be optimal.

Feb. 15, 2009

Re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Austin English

On Sun, Feb 15, 2009 at 3:37 AM, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: >> I don't want to be rude, but I have better things to do than >> propagandize my solution. We can live without such library in Wine, it >> would just require us to maintain separate libraries for different >> libc or wine versions. Having it in wine distribution would solve this >> problem smoothly, reducing our task only to maintain native Linux >> shared lib for hardware access. If anything changes in your position, >> let me know, I am willing to help with it. >> >> Martin >> > > So now and then things come by which would be useful for some Wine users / developers but which aren't suited for inclusion in Wine. Nonetheless I think we need a place where such things can be stored. http://code.google.com/p/winezeug/ ? -- -Austin

Feb. 15, 2009

Re: Updated cebit presentation. Looking for ideas...

by Marcus Meissner

On Sat, Feb 14, 2009 at 04:49:03PM -0800, Dan Kegel wrote: > I've been slowly finishing my cebit presentation. The current draft is at > http://kegel.com/cebit/ > > It now talks briefly about winetricks, > and uses firefox and safari as examples > of installing and running platinum and bronze > apps. > > It also talks more about support, since a > windows admin I showed it to said windows > admins were generally scared of trying to > support open source apps. > > If anyone has suggestions for how to make this > presentation more appealing/informative/convincing to > newbies who are only familiar with windows, > please let me know. > > Also, if anyone can tell my why firefox doesn't show the Windows logo > until you refresh sometimes, I'd be grateful. Maybe it's because > the same image is used twice in the same page? Btw, I have run my last 3 Wine presentations in OpenOffice_org 2.4 for Win32. Did not give much crowd "ooooh" effect though. Ciao, Marcus

Feb. 15, 2009

Re: Start DDE interface from Explorer Process. Add DDE stubs.

by Jeremiah Flerchinger

On Fri, 2009-02-13 at 17:10 +0800, Dmitry Timoshkov wrote: > "Jeremiah Flerchinger" <jeremiah.flerchinger(a)gmail.com> wrote: > > > Explorer.exe now calls ShellDdeInit. Progman stubs will now be started/used in Shell32. > > Amazingly any apps with a Progman DDE interface will also be called. Shell32 can handle > > all major functionality, but a running progman.exe (for example) will be able to > > synchronize internal values with changes made by Shell32. > > This patch just adds a lot of confusion and mess. As I suggested > you should start with a simple test app and see how it really > supposed to work. > Do you disagree that the Shell Dde interface must be actually running to handle DDE calls and that Explorer.exe should call ShellDdeInit & start the interface? I've taken the progman.exe stubs out of my local copy of the explorer/shell32 dde patch. I want to get 2 test cases working. The first is posted below and the second will use PostMessage & SendMessage for all DDE calls. I'll resubmit when I have time to flesh out the XTYP_EXECUTE stub in shell32. On another note, the lack of a terminal font makes the OEM_FIXED_FONT look unreadable - especially in 8x8 vga chars. I've been looking at old screen shots in an attempt to determine what the BIOS ROM font should look like in 8x8, 8x14, and 8x16. If I complete a sfd set with at least one of these sizes, would you help me get Wine to use it? Thank you -J

Feb. 15, 2009

Re: [3/3] WineD3D: Pass the requested srgb flag to PreLoad

by Henri Verbeet

2009/2/14 Stefan Dösinger <stefan(a)codeweavers.com>: > + SRGB_DONTKNOW = 0, /* Uses the cached value(e.g. external calls) */ SRGB_ANY or SRGB_EITHER is probably a nicer name. Do the enum elements need explicit values? You can probably drop the typedef as well, I don't think it adds anything useful. (I already mentioned some reservations about the extent of the changes to the internal interfaces for sRGB texture duplication on IRC, but lets merge it anyway and see where it goes.)

Feb. 15, 2009

Re: [2/3] WineD3D: Add a debug function for surface locations

by Henri Verbeet

2009/2/14 Stefan Dösinger <stefan(a)codeweavers.com>: > +const char *debug_surflocation(DWORD flag) { > + switch(flag & SFLAG_LOCATIONS) { > + case SFLAG_INSYSMEM: return "SFLAG_INSYSMEM"; > + case SFLAG_INDRAWABLE: return "SFLAG_INDRAWABLE"; > + case SFLAG_INTEXTURE: return "SFLAG_INTEXTURE"; > + case SFLAG_INSRGBTEX: return "SFLAG_INSRGBTEX"; > + > + case SFLAG_INSYSMEM | SFLAG_INDRAWABLE: return "SFLAG_INSYSMEM | SFLAG_INDRAWABLE"; > + case SFLAG_INSYSMEM | SFLAG_INTEXTURE: return "SFLAG_INSYSMEM | SFLAG_INTEXTURE"; > + case SFLAG_INSYSMEM | SFLAG_INSRGBTEX: return "SFLAG_INSYSMEM | SFLAG_INSRGBTEX"; > + > + case SFLAG_INDRAWABLE | SFLAG_INTEXTURE: return "SFLAG_INDRAWABLE | SFLAG_INTEXTURE"; > + case SFLAG_INDRAWABLE | SFLAG_INSRGBTEX: return "SFLAG_INDRAWABLE | SFLAG_INSRGBTEX"; > + > + case SFLAG_INTEXTURE | SFLAG_INSRGBTEX: return "SFLAG_INTEXTURE | SFLAG_INSRGBTEX"; > + > + case SFLAG_INSYSMEM | SFLAG_INDRAWABLE | SFLAG_INTEXTURE: > + return "SFLAG_INSYSMEM | SFLAG_INDRAWABLE | SFLAG_INTEXTURE"; > + case SFLAG_INSYSMEM | SFLAG_INDRAWABLE | SFLAG_INSRGBTEX: > + return "SFLAG_INSYSMEM | SFLAG_INDRAWABLE | SFLAG_INSRGBTEX"; > + case SFLAG_INSYSMEM | SFLAG_INTEXTURE | SFLAG_INSRGBTEX: > + return "SFLAG_INSYSMEM | SFLAG_INTEXTURE | SFLAG_INSRGBTEX"; > + case SFLAG_INDRAWABLE | SFLAG_INTEXTURE | SFLAG_INSRGBTEX: > + return "SFLAG_INDRAWABLE | SFLAG_INTEXTURE | SFLAG_INSRGBTEX"; > + > + case SFLAG_INSYSMEM | SFLAG_INDRAWABLE | SFLAG_INTEXTURE | SFLAG_INSRGBTEX: > + return "SFLAG_INSYSMEM | SFLAG_INDRAWABLE | SFLAG_INTEXTURE | SFLAG_INSRGBTEX"; > + > + default: return "Unknown location flag combination"; > + } > +} I think using wine_dbg_sprintf() would be a lot more practical.

Feb. 15, 2009

[patch] review requested: message-mode named pipes

by Luke Kenneth Casson Leighton

http://bugs.winehq.org/attachment.cgi?id=19477 * functionality of non-message-mode (byte type) is preserved. * putting too many messages into the queue runs wineserver out of file descriptors, but the solutions to that are too much work for this revision, to be included, so - tough. * research indicates that message-mode is supposed to block when resources are low, but that would require a per-file mutex. again - too much work for this revision. l.

Feb. 15, 2009

http://wiki.winehq.org/NamedPipes - documenting the samba / wine NamedPipes integration

by Luke Kenneth Casson Leighton

i've been updating this page with relevant information that is part requirements specification, part documentation. of particular relevance is the lack of support (in both tng and samba 3) for transferring SetNamedPipeHandleState semantics, although the "stub" functionality inside tng (smbd/pipe-proxy.c) at least records the NP message-mode flags, and then _completely_ ignores them ha ha :) exactly how this is to be implemented is unclear, and to be absolutely honest, by far the simplest-sounding approach may be to actually compile samba up as a win32 app! under such circumstances, it would be incredibly easy to then call the wine-emulated NamedPipe win32 functions CreateNamedPipe, SetNamedPipeHandleState etc. etc. given that samba tng has _already_ successfully been ported to win32, it has a head start here. and in that regard, ReactOS has it made, done and dusted! the alternative is... gaahd, i dunno... messy, to say the least, and *shudder* an mmap'd tdb is sounding _really_ attractive. tell me if this sounds reasonable. basically, a mini-wineserver protocol - a mini-SMB protocol - is required. commands to "send", "receive", "setnamedpipestate", "waitnamedpipestate" and "close". all required. * samba 3 / tng create or access named pipes as emulations over unix domain sockets, including sending a security context. in samba 3, that's called a SamInfo3, but it looks suspiciously like a NETLOGON NET_USER_INFO_3) and in tng it's a NET_USER_INFO_3... so... yep, it looks like just the name has been changed. * a program wants to create or access a named pipe; it asks wineserver (via a new function) to create or open up a unix domain socket. the locations will be the same. i.e. tng / samba3's unix domain socket pipe locations same as wineserver's. * sending / receiving of the security context blob is done in the dlls NOT in wineserver, so as to avoid blocking wineserver. * read, write, snphs, wnphs are all done with a 2-byte command prefix, followed by parameters, followed by data. exactly the same as is done in SMB and in wineserver. ... you know... if SMB wasn't so damn complicated i'd say bugger it, just send the SMBs to Wine, for _it_ to sort out!! in fact, with cliffsd's auto-generated SMB parsing code, that might even still be a valid option, given that the relevant code for parsing the SMBs is public domain. what do people think? does this sound like a reasonable proposition - a mini SMB/wineserver protocol - for use for inter-communication between wine and samba in order to exchange named pipe traffic? l.

Feb. 15, 2009

Re: [patch but not quite ready] NamedPipes messagemode

by Luke Kenneth Casson Leighton

> 5) running MSYS: fail. found it: rxvt.exe is looking for libX11.dll (!!) which is nothing to do with NamedPipes. running c:/msys/bin/sh.exe --login -i is: success.

Feb. 15, 2009

Re: 1.1.15 failing to build -- what changed?

by Hin-Tak Leung

--- On Sun, 15/2/09, Ben Klein <shacklein(a)gmail.com> wrote: > 2009/2/15 Hin-Tak Leung <hintak_leung(a)yahoo.co.uk>: > > > > --- On Sun, 15/2/09, Ben Klein > <shacklein(a)gmail.com> wrote: > > > >> 2009/2/15 Hin-Tak Leung > <hintak_leung(a)yahoo.co.uk>: > >> > I have no idea why suddenly at wine 1.1.15 it > requires > >> the > >> > x86_64-redhat-linux-{as,ld,nm} form of the > binutils > >> tools. It seems to treat x86_64 suddenly as a > >> cross-compiling environment. > >> > >> Are you sure nothing in the build environment just > happened > >> to change > >> in the last 2 weeks or so? > > > > Well, I do my weekly fedora update, so a few hundred > MB changes weekly. Given that this problem happens with both > Debian/Ubuntu systems and fedora, this week... and I have > had my rpmbuild system working smoothly for about a year... > > > > If I am going to guess, I think the change has > something to do with cross-compiling, instead of just the > occasional -m32 . > > scguy318 just brought this to my attention on IRC: > http://bugs.winehq.org/show_bug.cgi?id=17340 Argh... the original reporter of that bug seems to be rather mistaken - there is no need to have a separate cross-compile tool chain on 64-bit fedora (which I am also using) to build 32-bit applications. Just passing -m32 to both the compiler (CFLAGS for c , CXXFLAGS for c++ code and FFLAGS for fortrans) and the linker (LDFLAGS) would do. So to make it work for one person's peculiar build environment, everybody else's normal environment has to break...

Feb. 15, 2009