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

Re: notepad: Make the Lithuanian resources SUBLANG_NEUTRAL.
by Francois Gouget 07 Feb '09

07 Feb '09

On Sat, 7 Feb 2009, Aurimas Fišeras wrote: [...] > Since there is only one sublang SUBLANG_LITHUANIAN_LITHUANIA (1) it > probably doesn't matter which one to use. > > [1] http://msdn.microsoft.com/en-us/library/dd318693(VS.85).aspx#NotesPrim Actually Wine has two: #define SUBLANG_LITHUANIAN_LITHUANIA 0x01 #define SUBLANG_LITHUANIAN_CLASSIC 0x02 Which is why, unless we know the translation is really specific to one of them, we prefer to use SUBLANG_NEUTRAL. But you're right, the PSDK has only one sublang (I searched in all the sdks I have around here). The xxx_CLASSIC one came from this patch which does not really help us much: --- commit ca45823a347b6456b4eb36ae5de9c5b6e22ad959 Author: Pablo Saratxaga <srtxg(a)chanae.alphanet.ch> Date: Sat Oct 10 15:38:21 1998 +0000 More NLS data. --- Do we have any reason to keep the SUBLANG_LITHUANIAN_CLASSIC one? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Dieu dit: "M-x Lumière". Et la lumière fut.

1 0

Re: richedit: Removed unnecessary calls to ME_WrapMarkedParagraphs.
by Massimo Del Fedele 07 Feb '09

07 Feb '09

Dylan Smith ha scritto: > These calls to ME_WrapMarkedParagraphs never do anything, and don't make > sense to be called in these places. These places are for ME_MoveCaret, > and ME_ArrowHome, which both don't involve any text being modified, and > all (direct and indirect) calls to these functions are done after the > text has already been wrapped. > --- > dlls/riched20/caret.c | 3 --- > dlls/riched20/paint.c | 2 +- > 2 files changed, 1 insertions(+), 4 deletions(-) > > > ------------------------------------------------------------------------ > > This patch broke MTEXT and DDEDT autocad commands, see bug http://bugs.winehq.org/show_bug.cgi?id=17301 Ciao Max

1 0

tests with new DIB
by Evgeny Burzak 07 Feb '09

07 Feb '09

Hello, I make some tests and it show interesting results: * Archicad 10 and 11 can open plans, crashed of course and unusable, but with WINEDIB=OFF it didn`t work at all. * Flash 8 with WINEDIB=ON render fonts much faster. Screens and logs attached. colors of plans are wrong. Must be grey on white. -- Evgeny Burzak <buzzilo(a)gmael.сом>

2 1

Re: riched20: Remove unused functions
by Dylan Smith 07 Feb '09

07 Feb '09

On Sat, Feb 7, 2009 at 9:33 AM, Andrew Talbot <andrew.talbot(a)talbotville.com> wrote: > > @@ -65,17 +65,6 @@ ME_String *ME_MakeStringR(WCHAR cRepeat, int nMaxChars) > return s; > } > > -ME_String *ME_MakeStringB(int nMaxChars) > -{ /* Create a buffer (uninitialized string) of size nMaxChars */ > - ME_String *s = ALLOC_OBJ(ME_String); > - > - s->nLen = nMaxChars; > - s->nBuffer = ME_GetOptimalBuffer(s->nLen+1); > - s->szData = ALLOC_N_OBJ(WCHAR, s->nBuffer); > - s->szData[s->nLen] = 0; > - return s; > -} > - > ME_String *ME_StrDup(const ME_String *s) > { > return ME_MakeStringN(s->szData, s->nLen); I think that ME_MakeStringB should be made static, and the ME_MakeString functions should use it since it's code is repeated. I'll send a patch doing that so ME_MakeStringB doesn't remain unused. Besides that I agree with the changes, and was about to submit a patch that got rid ME_ConcatString while some replacing lstrcpyW calls in ME_AppendString that would truncate strings containing NULL bytes, since ME_ConcatString has the same problem. Maybe I should remove ME_ConcatString for you so that our patches don't conflict, since ME_ConcatString follows ME_AppendString in the code. Thanks for helping clean up some of that old richedit code.

1 0

Re: imagicos
by Ben Klein 07 Feb '09

07 Feb '09

Oops, forgot to Reply All. Sorry, Austin! 2009/2/7 Austin English <austinenglish(a)gmail.com>: > On Fri, Feb 6, 2009 at 7:30 PM, Ben Klein <shacklein(a)gmail.com> wrote: >> 2009/2/7 Austin English <austinenglish(a)gmail.com>: >>> On Fri, Feb 6, 2009 at 7:16 PM, Ben Klein <shacklein(a)gmail.com> wrote: >>>> 2009/2/7 EA Durbin <ead1234(a)hotmail.com>: >>>>> I just saw this linux distribution on distrowatch. They claim to be able to >>>>> run all microsoft products. Interesting. >>>>> http://www.imagicos.com/ >>>>> http://www.imagicos.com/microsoft.html >>>> >>>> No they don't. It says "almost every" on the home page and "most" on >>>> the "Microsoft" page. >>>> >>>> Assuming they're talking about Wine, someone should tell them that >>>> they're wrong anyway. "quite a lot of entirely win32 applications", >>>> maybe. Almost certainly not "most". >>>> >>>> Ooh, just spotted some interesting items on their "tested applications" list. >>>> - DirectX >>>> - DirectX 6 >>>> - DirectX 7 >>>> - DirectX 8 >>>> - DirectX 9 >>>> >>>> How about we just completely ignore these idiots? >>> >>> Also: >>> # Internet Explorer 5.0 and 5.5 >>> # Internet Explorer 6.0 >> >> I've heard of some success with 6.0 (without crappy >> winedoors/ies4linux stuff), so I didn't comment. >> >>> # iPod Support in iTunes 4.0 >> >> Hmm, that seems unlikely >> >>> # Mac OS X >>> # Mac OS X Audio Input Support >> >> Well spotted, Austin! >> >> Maybe they're talking about a VM, not Wine ... in which case, you'd >> have to get a copy of Windows, which defeats the purpose of being >> proud about their Windows app support. >> > > From http://www.imagicos.com/why.html : > "Compatibility > iMagic OS can run many Microsoft Windows applications along with Linux > applications, with help from the built in Crossover software." That might just explain why "CrossOver" is on their supported/tested apps list. Then again, maybe not. > Either they've got a deal with Crossover, or bundled it somehow? > > I sent them an e-mail asking for the source, we'll see how that goes. Not that I think it's worth talking about this for much longer, but also found these amusing: # Acrobat Reader 8 because there's no Linux-native version of that, is there? Oh wait, there is, and it's called Adobe Acrobat Reader 8 for Linux! # Adobe Creative Suite 2 (CS2) ... # Illustrator CS2 # InDesign CS2 ... # Photoshop CS2 Not trying to pad it out at all, are we? # The Orange Box which is not an application, but a box. Inside the box is HL2, Portal, TF2 etc # EVE Online ... # World of Warcraft # World of Warcraft Online OOOOOooooh online versions of MMORPGs! # Windows Media Player 6.4 # Windows Media Player 6.9 And ONLY THOSE SPECIFIC VERSIONS! Thanks, EA Durbin, you've made my day :D

1 0

Re: Stub DDE interface for Progman.exe
by Dmitry Timoshkov 07 Feb '09

07 Feb '09

"Jeremiah Flerchinger" <jeremiah.flerchinger(a)gmail.com> wrote: > Stubs basic DDE interface of Progman.exe. Similar to Progman stub in > shell32.dll. Both will need to be extended and a 3rd progman interface > will need to be added in user32. Progman DDE interface should be implemented by shell32.dll, nowhere else. -- Dmitry.

5 12

re: New Wine Gecko package
by Dan Kegel 06 Feb '09

06 Feb '09

James Mckenzie wrote: > It depends on the timeline for the 1.2 release. > If this is a long way off, it may be worth the effort. I don't know. The 1.1 branch has are lots of improvements people want; what's so special about Gecko? IMHO we should leave the 1.0 branch alone, and just get on with 1.2. Speaking of which, I wonder which of Alexandre's 1.2 wish list features will be done first? http://wiki.winehq.org/WineReleasePlan Win64 is looking like the front runner at the moment, but there were some USB patches recently, maybe that will come from behind.

3 2

[Fwd: WINE: suspected bug in change to winealsa.drv/waveout.c]
by Deomid Ryabkov 06 Feb '09

06 Feb '09

Maarten didn't reply, widening to wine-devel@ summary: looks like a bug was introduced into WaveOut queue management back in october that causes sound to skip and stutter. -------- Original Message -------- Subject: WINE: suspected bug in change to winealsa.drv/waveout.c Date: Sun, 25 Jan 2009 03:46:09 +0000 From: Deomid Ryabkov <myself(a)rojer.pp.ru> To: m.b.lankhorst(a)gmail.com hi, Maarten. i'm a complete noob in WINE, this is the first time i delved in the source, so please bear with me if i'm wrong, but i believe i traced a specific problem i've been having with sound in Heroes of Might and Magic III to a change you made couple months ago to the ALSA waveout driver. the regression manifests itself as rather annoying audio skipping and stuttering. having spent some time tracing and looking at the code, i believe that the problem was introduced by this change to dlls/winealsa.drv/waveout.c made on Oct 4: http://source.winehq.org/git/wine.git/?a=commitdiff;h=717df5b2972b3cb998ca5… specifically, this line + wwo->dwPlayedTotal += lpWaveHdr->reserved - wwo->dwPlayedTotal; advances the dwPlayedTotal watermark when i believe it shouldn't. fundamentally, only DSP can report how much has been played, updating this pointer after reporting that a sample has been played makes no sense. DSP has reported that it has played up to a certain point that covers the sample in question, we are reporting this back and removing the sample. we should *not* be changing the value DSP sent us. i don't know what was the specific issue you were addressing with the patch in question, but i'd like you to take one more look at it, because removing this one line fixes skipping and stuttering for me. if you need any more information, please feel free to ask. -- Deomid Ryabkov aka Rojer myself(a)rojer.pp.ru rojer(a)sysadmins.ru ICQ: 8025844 -- Deomid Ryabkov aka Rojer myself(a)rojer.pp.ru rojer(a)sysadmins.ru ICQ: 8025844

1 0

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/smbsrv/ndl/
by Luke Kenneth Casson Leighton 06 Feb '09

06 Feb '09

holy cow. opensolaris appears to have its own smb server / idl compiler: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/tools/ndrgen/ CDDL licensed, unfortunately (listed as incompatible with GPL. darn). but... dang :)

1 0

http://wiki.winehq.org/NamedPipes
by Luke Kenneth Casson Leighton 06 Feb '09

06 Feb '09

rob, hi, regarding the above wiki page - there is no "obstacle". you can use any of the code that i wrote for samba (about 100,000 lines of code), i released all of it into the public domain, on dec 16th, 2005. there's enough there so that you can do an entirely "hands off" approach, getting packets in and out using (see last post!) surprise,surprise, emulated named pipes. what i did for tng was to create a "packaging" system which sent security contexts (complete security descriptors and other identifiying information) over a unix socket. it was completely transparent as far as smbd was concerned, which just "handed it around" to the appropriate daemons. i asked jeremy to add in simple support for this into main samba several times. the last time (dec 2005) once _again_ he fucked about, but did actually agree that it was a good idea. samba having "break-out" for named pipes traffic is one of those absolutely _essential_ things that should have fucking well gone into the samba source code a _long_ time ago. around 1998 would have been good. _several_ projects would enormously benefitted - including samba - if that had happened. sun microsystems, who bought the [well known to be a complete piece-of-crap] port of nt to unix, AFPS, for $USD 4m and were utterly appalled by the poor quality of the implementation of the smb server gave serious consideration to dumping it, keeping the MSRPC services, and riding off the back of samba.... .. via _guess what_! a named pipe "break-out" interface. which, of course, doesn't exist. so they couldn't do it. but gordon did discuss it with me, saying things like, "y'know, if samba had a way in to its named pipes interface..." and guess what? in order for you to do named pipes via samba, you need a named pipe "break-out" interface. guess how luke howard implemented XAD (which he sold to novell a couple of years ago)? he implemented a patch to samba which provided a named pipe "break-out" interface. that patch was released back in about 2002 and has never been incorporated into samba. the protocol for a break-out interface is very simple: you need four functions ( and they can be done in as little as about 300 lines of c-code, as a patch to samba) 1) open named pipe connection 2) read pipe 3) write pipe 4) close pipe if you implement that in a dynamically-loadable .so, style, as a vector table (see e.g. apache2 module interface for example) then you can dump a .so into a directory which samba can pick up. any data that comes in from SMB will then "activate" the .so, call the open_named_pipe function in the vector table, and you're away. you release the code of the .so under the LGPL, that gets "GPL'd" by samba, license problem is solved. so, with a small patch to samba, the means to take control of the direction of wine is within _your_ hands. because the dynamically loadable .so conforms to the "break-out" interface and is loaded _by_ samba, on demand, and the code in it is part of Wine and communicates using Wine protocols - entirely under your control. ... you know... it would actually be a lot easier to integrate wine with samba tng, because the infrastructure to communicate by emulated NamedPipes already exists. take a look at the following functions: ncalrpc_l_connect ncalrpc_l_close_socket receive_msrpc msrpc_send all of which are in lib/msrpc-client.c - you'll see in there that there are corresponding functions for the samba tng win32 port - CreateNamedPipe, ReadFile, WriteFile, WaitNamedPipeHandleState, CloseHandle etc. which will help give you some _really_ big clue-handles to understand the corresponding "emulating" functions using unix sockets. you _should_ also recognise the ncalrpc_srv_get_user_creds function and its equivalent client-side "sender" ncalrpc_l_authenticate. these two are a matched pair of functions which marshal and unmarshal an NT security context [based on a NET_USER_INFO_3 structure - recognise that one? :) it's a stub in wine - now you have some code that gives it purpose! ] basically after a connect (ncalrpc_l_connect) the client sends the user creds _immediately_, and the server picks them up, and saves them in its internal context (for later passing around etc). also they end up getting used to do seteuid() but as the entire protocol was used by root _only_ it was perfect safe to do this. the unix sockets were protected 600 with the directory they were in being protected 755 because some unixen _still_ bloody well let you access a unix domain socket even if its permissions were 600, all owned by root, all services running _as_ root, so one daemon being a client passing over a security context that told _another_ daemon running as root to seteuid to a user's uid was no big hairy deal. except that andrew thought that i was some sort of fucking 17-year-old incompetent student, and he didn't like the thought of me actually being a capable unix systems programmer. thus, this code could be justified as never going into samba (even though a similar implementation was designed _by_ him for use in winbind). _really_ interesting bit of hypocrisy going on there. the sad thing is that it's stopped _so_ much progress in free software, it's unreal. anyway - you can pick up that code with: cvs -d anoncvs(a)anoncvs.samba-tng.org:/home/cvsroot co tng it's anoncvs - just press return look in tng/source/lib/msrpc-client.c btw don't be fooled into thinking that just because you're on loopback - running samba and wine on the same machine and only processing requests that come in or go out over 127.0.0.1 - don't be fooled into thinking that you can throw away the security context (the NET_USER_INFO_3 stuff) - you can't. you _really_ need to keep it around, and pass it back-and-forth. so - to recap what the protocol / procedure is: * a small .so has already been dropped into samba's lib/ directory which has been dynamically-loaded; any SMB-based "NamedPipe" traffic that is NOT destined for internal samba services (such as \\PIPE\lsarpc etc) is handed to this .so. the .so, when an incoming "ConnectNamedPipe" request is made, will direct the contents, pretty much verbatim BUT pre-pending the security context "blob" (see above) to any initial connects. * any win32 programs that call CreateNamedPipe will result in a call .. ... you know what? this is getting complex - and i'm spending quite a bit of time writing it. i designed this stuff, once, and it worked. wine needs it. samba needs it. so, i'm really _really_ sorry to have to bring this up - but it's a quite important point: if you can find someone to pay for the necessary development, i'm more than happy to do the work. i'm also happy to help advise people on how this can be implemented (if the above clues and directional guides aren't enough) it's been ten years since this kind of cross-project integration stalled: i've watched the development of wine go its way, and samba go its way, and ntfs filesystem drivers for linux go _their_ way, and all of these projects don't _actually_ cooperate or link together properly. nobody's actually _paid_ any fucking money to coordinate and liase with these projects. there's people paid to work on linux; there's people paid to work on wine; there's people paid to work on samba. and the only people who really suffer for lack of this really important strategic interoperability is: users. so can we _please_ pull our collective fingers out of our arses, get some sponsorship and funding from _somewhere_ and get moving? that last said with the utmost of respect :) l.

2 5