- wine-devel - winehq.org

Re: lostwages: todo_lists.diff
by Michael Stefaniuc 09 Feb '04

09 Feb '04

Hello, On Sun, Feb 08, 2004 at 01:01:49PM -0500, Tom wrote: > Here is the new revised 0.9 todo_lists it is based on the criteria that we > talked > about at WineConf for a 0.9 release.. At this time we have 4 [DONE], 34 [IN > PROGRESS] > and 18 [TODO] items. So if you woul'd like to volunteer for a item just let > the list know > and we will add you as the current worker. I would keep the old [DONE] items, the page looks better in mostly green. Could maybe motivate some more people to tackle the last remaining problems. Btw. the status of the "Cross compilation on RH" is [DONE] and please use RHL for the abbreviation. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

Bug compatible?
by Fabian Cenedese 08 Feb '04

08 Feb '04

Hi Looking for something else I found this in wine/objects/font.c: GetTextExtentPointA/W: TRACE("not bug compatible."); As funny as it is it doesn't say that much. Is this referring to a bug in Windows? And in what way not compatible? Maybe there should be some comment explaining it. Thanks bye Fabi

3 5

Problem with Quicken crashing: Help, please!
by Carl Sopchak 08 Feb '04

08 Feb '04

Hi, Since about mid-December, I've had an issue running Quicken 2000 Deluxe using the CVS version of wine. The symptom is that *sometimes* (I hate that word when trying to debug!) the program crashes when printing a partial page of checks (landscape, centered, 1 or 2 checks on the page, not 3). When it happens (mostly when I'm trying to print real checks, not when I'm trying to debug the problem - argh!), it always happens after Quicken asks if the bottom tear-off part of the page of checks is still attached, and I click the Yes button. The actual error that I get is an X error, stating that X has run out of resources. The reason for that is that it's trying to create a bitmap with dimensions 1,075,900,608 by 1,082,644,840. Of course it's gonna run out of resources! Running it with --debugmsg, I see that this size is being passed to either CreateBitmap() or CreateCompatibleBitmap() in several places. I have added TRACE() statements before every call to either of these two functions that I can find in the wine source, displaying the values. Unfortunately, I don't see my trace statements in the log (created by redirecting wine's output with --debugmsg +all,-snoop,-win32,-heap) before the "bad values". (I DO see the statements for other calls, as well as those I put within CreateBitmap, so they are getting compiled, etc., correctly...) I have spent a few days - on several occasions - trying to debug this, but I keep running into a brick wall. Before I go much further here, I gotta say that besides other debugging of wine that I've done in the past, I know little to nothing about the Windows API, or the internals of wine. I can't call myself a C expert, either. (I have been a computer consultant for 20+ years - just on other platforms - so I consider myself competant in general debugging and various languages. Picking up C, so far, hasn't been that big of a deal. But I certainly don't know many of the nuances!) That said, here are the questions that I'm hoping someone can help me with so I can continue the debugging process: 1) I'd LOVE to use --debugmsg +snoop, but when I do this, the text box Quicken displays (within the Print Checks dialog) for the user to enter the first check number to print does not get displayed, and the program gives an "invalid check number" error, and I never get to the point that the program crashes. So, as an alternative to tracking down and trying to fix this debugging bug (which I really don't have the expertise [or, frankly, desire] to do in a reasonable amount of time), I was wondering if there was a data structure available that I could use in relay.c that would get me the CALLING procedure name, so that I could add the DPRINTF statements to show who called CreateBitmap / CreateCompatibleBitmap with the "bad values". Any help - as specific as possible - would be greatly appreciated... (Trying to follow all of the calls and returns gets pretty confusing pretty fast!) Or, if anyone has a clue on why +snoop would cause the textbox problem... 2) Now, for my lack of C knowledge: When adding the TRACE() statements, I found several places where the width and height parameters being passed to CreateBitmap and/or CreateCompatibleBitmap and/or CreateDIBitmap were not INT. For example (approximate line numbers in []) dlls/conctl32/animate.c[224], listview.c[4051], trackbar.c[799], treeview.c[4004], objects/dib.c[183], and metafile.c[1037] all pass LONG's, and dib.c[825] passes width as a DWORD, and height as an int. (This seems to be a potential issue relating to the function DIB_GetBitmapInfo, as the width an height fields of the data structures passed in as *header are LONG, except if *header is of type BITMAPCOREHEADER, where it's WORD, but they are being passed back to DWORD and int pointers.) Does the C compiler do an implicit conversion of these data types to INT (correctly), or is the fact that parameters are too big suspect in causing my problem? Can I just assign a LONG (and DWORD) to an INT (i.e., iWidth = lWidth) to do the conversion? Hopefully, these are simple enough questions for someone with the knowledge to answer and get me back on track to solving this issue. Any and all help will be greatly appreciated! Thanks, Carl P.S., I think my next step is going to restore my wine source tree from my November (October?) backup, and make sure the issue is in fact something that's changed in wine, and not some configuration change that's happened. (Althought I'm not certain of the timing, in the same time frame, I've attempted to install IE6, installed TaxCut 2003 (which required IE6 dlls, and seems to run, BTW. I haven't done my taxes yet, though...), and played with fonts some.

1 0

Re: shell32 patch 12
by Mike McCormack 08 Feb '04

08 Feb '04

This patch broke the installation of IE6. When running the command below during installation of IE6, a pathname is scribbled over the stack... C:\windows\inf\unregmp2.exe /Shortcuts /IE5 /RegExts Any ideas why? Mike Martin Fuchs wrote: > This patch is based on work of Ge van Geldorp <ge(a)gse.nl> and me. > > Changelog: > reimplementation of SHGetPathFromIDListA/W() using the new helper > functions SHELL_GetPathFromIDListA/W(). The new implementation avoids to > use IShellFolder::GetDisplayNameOf(), so that it behaves like the following: > > - return the absolute file system path, not relative to the dekstop > - return FALSE as error code if the path can not converted in a valid file system path > - don't return virtual CLSID paths > > Note: > The two helper functions will we called from other places in following patches, so they > are declared in the header file.

2 2

manpage slimmed down?
by cedric 08 Feb '04

08 Feb '04

Hi, recently i upgraded from 20031118 to 20040121. I noticed a lot of bugfixes and speed increases. Thanks! However, i don't like the new man.1 page as much as i did the one from 20031118. The section about what debug channels wine has is gone. This was nice info to have under 'man wine'. Why is it removed? Regards, cedric P.S. Sorry for posting a complaint as my very first post to this list. -- No microsoft products were used for this e-mail

4 4

IE6 Security Controls/URLMon;msimtf (nhl 2004)
by Abdul-Haseeb Ahmad 07 Feb '04

07 Feb '04

Okay when i use IE6 (installed by mike's script) any webpage that uses an activex control says my security settings are too high, even if i lower them (both custom settings and the slider have no effect), or even if i make the site a trusted website... now i believe this might be what be causing problems with NHL2004 because i get a script error 80040154 (which doesnt let me go in game) when i go to the game setup screen(rest of the game is flawless other than DXImageTransform filters not functioning), which is caused by a missing CLSID entry.. so i checked out the errors I was getting and urlmon.dll wasn't registered and neither was msimtf... now the thing that nhl was trying to call was the security manager which is part of urlmon.dll.. when i registered urlmon, it would crash the game, and i can't get msimtf to register because of problems it has with advapi32/user32 implementations... Im not sure what msimtf does, but i have a hunch that clearing the urlmon issue might solve my problems.. anyone have an idea of what i can do to solve this issue? Theres also an error: fixme:system:SystemParametersInfoA Unknown action: 8198 I have a feeling this is harmless though...

2 4

Are bugzilla patches getting in?
by Leonardo Quijano Vincenzi 07 Feb '04

07 Feb '04

Hello everybody. I'm new to the developers list. I have a question about patches in bugzilla. Do developers usually read the bug reports to check for patches? Or is it better to send them directly to wine-patches? I'm talking about the following (minor) bugs, just in case: http://bugs.winehq.org/show_bug.cgi?id=1980 http://bugs.winehq.org/show_bug.cgi?id=1981 Thanks in advance. -- Leonardo Quijano Vincenzi <lquijano(a)hotpop.com>

4 5

Update: starcraft runs faster from debugger!
by cedric 07 Feb '04

07 Feb '04

crossposted to wine-dev, and wine-users Hi, I've done some more tests, and i found that when i run winedbg starcraft and wine starcraft and then again winedbg starcraft etc. It works, but always following this pattern: <boot my box> winedbg starcraft :all runs perfectly wine starcraft: all video choppy winedbg starcraft :all runs perfectly winedbg starcraft: all video choppy wine starcraft all video choppy winedbg starcraft: :all runs perfectly Looks like winedbg leaves some things in a bad state, and running wine seems to solve the problems. However, after each run of winedbg i have 4 more of these: 1797 pts/0 00:00:01 wine-kthread <defunct> And after about 4 or 5 times trying the wine trick doesn't work anymore, Whatever i do the game starts choppy. I don't know how to trace a program while it's running from the debugger, winededbg --debugmsg +x11drv <prog> doesn't seem to work. How is the corrrect startline? The trace from wine shows that DGA is disabled (even with /dev/mem set at 777) Can somebody confirm this pattern of events? you need ,wine-20040121 (haven't tried other versions) and starcraft retail or starcraft shareware to reproduce this. The shareware version of starcraft should be available at: www.blizzard.com Regards, cedric -- No microsoft products were used for this e-mail

2 1

programs/winedbg/elf.c breaks non-Linux platforms
by Gerald Pfeifer 07 Feb '04

07 Feb '04

Hi, I'm afraid the following patch which added programs/winedbg/elf.c date: 2004/02/03 00:14:12; author: julliard; state: Exp; Eric Pouech <pouech-eric(a)wanadoo.fr> - now detecting Dwarf debug information in ELF modules (but don't load it) - separated module management (pe.c, elf.c) from debug information management (stabs.c, msc.c) - worked around new wine-pthread and wine-kthread loaders (no longer use "wine" as default loader) - better convergence of gdb-proxy and winedbg for ELF handling - fixed ELF link-map walking - now using all loaded shared libs - (with the help of Robert Shearman) - added a bit of const correctness breaks building Wine on non-Linux platforms. For example, on FreeBSD 4.9 I'm seeing: elf.c: In function `DEBUG_ProcessElfFile': elf.c:344: error: `DT_NUM' undeclared (first use in this function) elf.c:344: error: (Each undeclared identifier is reported only once elf.c:344: error: for each function it appears in.) elf.c:344: error: `DT_PROCNUM' undeclared (first use in this function) elf.c:344: error: `DT_EXTRANUM' undeclared (first use in this function) elf.c:345: error: `DT_LOOS' undeclared (first use in this function) elf.c:345: error: `DT_HIOS' undeclared (first use in this function) elf.c:346: error: `DT_LOPROC' undeclared (first use in this function) elf.c:346: error: `DT_HIPROC' undeclared (first use in this function) Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

3 4

Wineboot should process RunOnceEx Entries
by Geoffrey Antos 07 Feb '04

07 Feb '04

I saw early postings about RunOnceEx in this mailing list circa January 2003, however the problems they presented were never fixed. Some programs come with simple INF installers because people can cheaply create an INF file, and use a free Setup.exe bootstrap file that reads the name of an INF file from Setup.ini or something similar. These programs do not have any way of processing RunOnceEx themselves. In the distant past before I had converted to Linux and wine, I used to deal with such programs quite a bit; RunOnceEx was Microsoft's way of allowing simple installers to register files, especially if a reboot and wininit was necessary to overwrite files. The basic structure of the registry format is: [Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\Number] "Number"="program.exe arguments" "Number"="c:\\somepath\\somedll.dll|SomeExportedFunction" Number is nothing more than a number. All commands are processed in sequential order, first by key, then by value. If there is no pipe symbol in the line ('|'), the data of the value is executed as a program, with all following tokens passed on as arguments. However, if the pipe symbol is included, the portion to the left is treated as a DLL, and calls the exported function of the name to the right of the symbol. Once all values in a key are processed, the key is deleted, and the process starts with the next key. There is one subkey that has a special meaning: All keys/values in [Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\Setup] are not processed at boot-up. Rather, they are read by the program runonce.exe, not included in wine. It is through this key that one gets the annoying "Updating Windows" box in the upper left corner of the screen, listing tasks being performed. I believe Powertoys for Windows 98 utilized this feature, but I do not remember how. However, these days RunOnceEx still has one important feature: Some people, like me, have programs that fail to load objects because the OS version is not set to XP. When the OS is set to xp, the install-ie6 script does not automatically process the RunOnceEx keys, failling to register all of the DLL's, including the Crypto support needed for programs such as Steam. As such, for IE6 alone, users have to process 50+ lines by hand, in something that SHOULD be processed at bootup, via wineboot.

3 3

Update: starcraft runs faster from debugger!
by cedric 07 Feb '04

07 Feb '04

crossposted to wine-dev, and wine-users Hi, I've done some more tests, and i found that when i run winedbg starcraft and wine starcraft and then again winedbg starcraft etc. It works, but always following this pattern: <boot my box> winedbg starcraft :all runs perfectly wine starcraft: all video choppy winedbg starcraft :all runs perfectly winedbg starcraft: all video choppy wine starcraft all video choppy winedbg starcraft: :all runs perfectly Looks like winedbg leaves some things in a bad state, and running wine seems to solve the problems. However, after each run of winedbg i have 4 more of these: 1797 pts/0 00:00:01 wine-kthread <defunct> And after about 4 or 5 times trying the wine trick doesn't work anymore, Whatever i do the game starts choppy. I don't know how to trace a program while it's running from the debugger, winededbg --debugmsg +x11drv <prog> doesn't seem to work. How is the corrrect startline? The trace from wine shows that DGA is disabled (even with /dev/mem set at 777) Can somebody confirm this pattern of events? you need ,wine-20040121 (haven't tried other versions) and starcraft retail or starcraft shareware to reproduce this. The shareware version of starcraft should be available at: www.blizzard.com Regards, cedric -- No microsoft products were used for this e-mail

1 0

Re: PATCH: virtual fixes for native mode
by Juan Lang 07 Feb '04

07 Feb '04

Hi Uwe, in NT the native (system call) interface is through ntdll. There are a number of subsystems implemented on top of that: the win32 subsystem, the posix subsystem, and the OS/2 subsystem. It's possible however to write an app that just uses ntdll; this is a "native" NT app. This page has a pretty good explanation: http://www.sysinternals.com/ntw2k/info/native.shtml --Juan __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

2 1

Re: PATCH: virtual fixes for native mode
by Uwe Bonnes 06 Feb '04

06 Feb '04

>>>>> "Marcus" == Marcus Meissner <marcus(a)jet.franken.de> writes: Marcus> Hi, This is the next try for assisting loading NT native dlls. Marcus> We need non-page aligned access for those drvs, which have Marcus> sections that are not page aligned. Marcus> Also some bad magic tries to write the import thunks into Marcus> thefirst page, so we need to map the header r/w too. Marcus> Ciao, Marcus Marcus> Changelog: Added possibility to map native mode dlls which have Marcus> sections that are not page aligned. What are native NT dlls? An explanation is appreciated! Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: DOC: improvement to the cross-compiling of the tests (take 2)
by Dimitrie O. Paun 06 Feb '04

06 Feb '04

On Fri, 6 Feb 2004, Michael Stefaniuc wrote: > Hello, > > Alexandre, please use this patch instead. Funny, funny :) -- Dimi. P.S. No patch attached.

1 0

Re: DOC: improvement to the cross-compiling of the tests doc
by Dimitrie O. Paun 06 Feb '04

06 Feb '04

On Fri, 6 Feb 2004, Michael Stefaniuc wrote: > here is an updated documentation for the cross-compiling of the Wine > tests with MinGW. You can safely drop the reference to that patch, things have been fixed since then. Even if they aren't, it's not the place for such kind of information. And while you're at it, maybe you can also include the instructions about cross-compiling the entire Wine tree. :) -- Dimi.

2 1

Re: OLEPictureImpl_Load: fix for headerless pictures
by Fabian Cenedese 06 Feb '04

06 Feb '04

>> Where did you disable it? My patch or yours? With my patch it should >> never even get to try to call CreateIcon (which fails). So either the >> field is not 0 or you don't jump out. > >I juste removed my header[1]==1, so you can say i rejected my patch. > >> >MessageBox with >> >"Failed to load control 'SSTab' from TABCTL32.OCX. Your version of >> >TABCTL32.OCX is outdated...." >> >> This is the error I wanted to eliminate, just look for my postings with >> SSTAB in the subject in the last two months :) >> When I jump out if header[1] is 0 then I don't get this error anymore >and >> VB programs with the SSTab control come up. But I only tried those >> without icons as I assumed that those with icons don't have a 0 field. >But they do have 0 field... > >I can't help you until i see how your app is supposed to work. >Please make sure the programm runs without (header[1]==0). That's the point, it doesn't work on wine in the current state. That's why I try to fix wine. Use my patch (even if it's wrong for your progs) then my app should come up and you can test what's going on. This bug in wine prevents many VB apps from running on wine. And as we have some of them I tried to fix it. bye Fabi

2 1

Out of the office and all of that.....
by Steven Edwards 06 Feb '04

06 Feb '04

Sorry if you have had mail bounced to me and all of that. I am still on post-wineconf vacation until monday and my mailbox is a little overflowing. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

1 0

Wrong short filenames instead of long ones
by Fabian Cenedese 06 Feb '04

06 Feb '04

Hi I'm trying to find a file copy tool which works on windows as well as wine. I tried several and this looked promising: ftp://ftp.simtel.net/pub/simtelnet/msdos/fileutil/cc108dos.zip On Windows it copied all files without problems and kept the long filenames even if the name implies that it's DOS-only, but it worked fine on W2K. But on wine the long names where all shortened to something like CINO~E2H.CPP. So it doesn't look like normal DOS short names ...~1.cpp but it's not the long name either. Can anybody try this out? My wine (actual cvs) config is set to windows version nt40. Thanks bye Fabi

3 3

File probably truncated
by Thomas Brix Larsen 06 Feb '04

06 Feb '04

Hi again, I'm getting stuff like this when trying to use Windows programs: 0009:trace:module:map_image mapped PE file at 0x400000-0xf89000 0009:trace:module:map_image mapping section .text at 0x401000 off 1000 size 6a4000 flags 60000020 0009:err:module:map_image Could not map section .text, file probably truncated Why? Anybody please? -- Thomas Brix Larsen <killar(a)get2net.dk>

4 5

Re: OLEPictureImpl_Load: fix for headerless pictures
by Fabian Cenedese 06 Feb '04

06 Feb '04

At 12:58 06.02.2004 -0500, Kirill Smelkov wrote: >On Fri, 6 Feb 2004, Fabian Cenedese wrote: > >[...] >> >I can't help you until i see how your app is supposed to work. >> >Please make sure the programm runs without (header[1]==0). >> >> That's the point, it doesn't work on wine in the current state. That's why >> I try to fix wine. Use my patch (even if it's wrong for your progs) then >> my app should come up and you can test what's going on. >> This bug in wine prevents many VB apps from running on wine. And as >> we have some of them I tried to fix it. > >Maybe i missed something (is so, i'm sorry), but where do i get your >patches? I sent it to wine-devel, but I can't access winehq at the moment (down?) so here it is again. It's just jumping out if header [1] is 0 (which works for me but I guess it's wrong for your programs). Index: dlls/oleaut32/olepicture.c =================================================================== RCS file: /home/wine/wine/dlls/oleaut32/olepicture.c,v retrieving revision 1.30 diff -u -r1.30 olepicture.c --- dlls/oleaut32/olepicture.c 5 Sep 2003 23:08:33 -0000 1.30 +++ dlls/oleaut32/olepicture.c 29 Jan 2004 16:19:25 -0000 @@ -873,6 +873,9 @@ hr=IStream_Read(pStm,header,8,&xread); if (hr || xread!=8) { FIXME("Failure while reading picture header (hr is %lx, nread is %ld).\n",hr,xread); + return hr; + } + if (header[1]==0) { return hr; } if (header[1] > statstg.cbSize.QuadPart) {/* Incorrect header, assume none. */ bye Fabi

1 0

Sending patch for bug 1848
by Andreas Rosenberg 06 Feb '04

06 Feb '04

Hi folks, I sent a patch for bug 1848 already twice. 1st time in the first half of december. 2nd time last week. Other stuff seems to be commited into the CVS. I was wondering, why my patch is not accepted. Can't you keep the pace commiting the patch into the CVS as they are sent to you? Is something wrong with my patch? Wrong diff format, style, break's something??? It the bug being fixed "to small" to include the patch? - Andy

2 1

32bpp bitmaps
by Kevin Koltzau 06 Feb '04

06 Feb '04

I am loading a 32bpp bitmap from resources of a dll, but under wine its being reported as 24 bit..for example void main() { HMODULE hTheme = LoadLibrary("C:\\Windows\\Resources\\Themes\\Luna\\Luna.msstyles"); HBITMAP hBmp = LoadBitmap(hTheme, "BLUE_BUTTON_BMP"); BITMAP bmp; GetObject(hBmp, sizeof(bmp), &bmp); printf("bpp=%d\n", bmp.bmBitsPizel); } under Windows prints 32, under Wine prints 24 I've tried to find the cause of this, but much of this is deep in x11drv which I am not familliar with at all.. Is wine stripping the alpha channel for some reason? or is this a bug? (I've only run this example on that one file, its the native Luna.msstyles theme from an XP system)

2 3

Re: Wine - update for Who's Who page
by Tom 06 Feb '04

06 Feb '04

Brian Vincent wrote: > One of the to do items is update the Who's Who list on WineHQ. If > you look at it right now it's horribly out of date: > http://www.winehq.org/site/who Yea.. The idea is to create an Acknowledgment page for the guy's that are currently inactive, or just have a link to the authors.. (???) > > This is an opportunity to both recognize you for your contributions > and serve as a way to promote Wine. After talking with Dimi at Wineconf > it became immediately apparent that being immortalized on WineHQ will > lead to hordes of beautiful women knocking on your door. When I first started using linux everyone talked about all this free beer.. Now we get wemon to boot.. :-) > > I think the format will remain similar; What I was going to do is not have the CodeWeavers section, VIPs/Core Devel/etc categories, as maybe some people don't like classifications. There are developers from CodeWeavers, TransGaming, ReactOS and so on.. The best thing would be to just have a affiliation attribute to each person. This way the more developers they have working on wine the more linkage they receive. This is a "Wine" Who's Who! Should we add a small pic of each developer to there section? Comments or idea's are most welcome. Tom

1 0

Re: OLEPictureImpl_Load: fix for headerless pictures
by Fabian Cenedese 06 Feb '04

06 Feb '04

>> >Then what type of picture it is? >> > >> >0x4947 GIF >> >0xd8ff JPEG >> >0x4d42 BMP >> >0x0000 ICON >> >0x746c ??? >> >> Well, as I didn't use any pictures I don't know what it's supposed to be. >> Might as well be "NoPic" :) But I have also seen this marker where the >> second field was not zero. > >It's probably some ole-storage magic. Don't know as i have no clue on how >ole works at all :) Neither do I :) >> Maybe this isn't even part of a picture and we shouldn't be reading this. >> How does it know that a picture is coming? Perhaps we shouldn't >> even enter OLEPictureImpl_Load if there is no picture at all. > >Fabi, > >I temporarly disable checking for (header[1]==0). even in such case your >test-case doesn't start: >fixme:ole:CoRegisterMessageFilter stub >fixme:ole:OleLoadPictureEx >(0x418ae294,774,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x4075fb08), >partially implemented. >fixme:ole:OleLoadPictureEx >(0x418ae294,774,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x4075fad8), >partially implemented. >fixme:ole:SPCF_CreateInstance >(0x40acdbc8,(nil),{7bf80980-bf32-101a-8bbb-00aa00300cab},0x402313a4), >creating stdpic with PICTYPE_NONE. >fixme:ole:SPCF_CreateInstance >(0x40acdbc8,(nil),{7bf80980-bf32-101a-8bbb-00aa00300cab},0x40231aac), >creating stdpic with PICTYPE_NONE. >fixme:ole:OLEPictureImpl_Load CreateIcon failed. >fixme:ole:OLEPictureImpl_Destroy Unsupported type 0 - unable to delete >fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet. Where did you disable it? My patch or yours? With my patch it should never even get to try to call CreateIcon (which fails). So either the field is not 0 or you don't jump out. >and then > >MessageBox with >"Failed to load control 'SSTab' from TABCTL32.OCX. Your version of >TABCTL32.OCX is outdated...." > >Does it work at all? This is the error I wanted to eliminate, just look for my postings with SSTAB in the subject in the last two months :) When I jump out if header[1] is 0 then I don't get this error anymore and VB programs with the SSTab control come up. But I only tried those without icons as I assumed that those with icons don't have a 0 field. >If so, then we probably should figure out whethere there are some >ole-storage magic present and chek for them when decidign whether to look at header[1] and how to interpret it. This is definitely above me. Maybe some guru can help here. Who's a pro in ole pictures? Picking anyone's pride? :) bye Fabi

2 1

App compiled with Delphi5 works, same App with Delphi7 does not.
by Samuel Herzog 05 Feb '04

05 Feb '04

Dear Newsgroup, I have downloaded and installed Release 20040121. I have a very small application (for testing purpose) which I can compile with Delphi 5,Delphi 6,Delphi 7. The application compiled with Delphi5 works fine. The same application compiled with Delphi7 shows an exception <EAccessvioalation in Module zxtheme.dll at 00006A71>. Any hints what to do ? Thank you, Samuel Herzog

3 4

Investigating the XInitThreads deadlock bug
by Sami Aario 05 Feb '04

05 Feb '04

Hi all, I decided to investigate this old bug: http://www.winehq.com/hypermail/wine-devel/2003/12/0158.html even though Alexander removed thread initialization from x11drv. So the first thing I did was apply this patch: Index: x11drv_main.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/x11drv_main.c,v retrieving revision 1.87 diff -u -r1.87 x11drv_main.c --- x11drv_main.c 30 Jan 2004 22:54:39 -0000 1.87 +++ x11drv_main.c 1 Feb 2004 18:02:26 -0000 @@ -332,6 +332,8 @@ /* Open display */ + if (!XInitThreads()) ERR( "XInitThreads failed, trouble ahead\n" ); + if (!(display = XOpenDisplay( NULL ))) { MESSAGE( "x11drv: Can't open display: %s\n", XDisplayName(NULL) ); I determined that the tests under user/tests were causing deadlock. The attached file debugrun1 shows this. Start the debugger with: winedbg user32_test.exe.so and repeat the steps I made, and the executable should deadlock at the call to XGetScreenSaver. (By the way, I used a version of the tests where I'd commented out all other tests except the test_SPI_GETSCREENSAVEACTIVE one, and that's why you only see "testing SPI_{GET,SET}SCREENSAVEACTIVE", but that's not important.) Next, I decided to investigate which mutual exclusion primitive is causing the trouble. This run is included as debugrun2. There are two threads involved: thread 0xb is the application main thread, and 0xe is a thread created by the main thread to generate the tests. Thread 0xb owns a critical section that 0xe wants, and hence deadlock. Note the call to "walk thread" in the beginning. Note also that I single-stepped thread 0xe right up to the call to RtlpWaitForCriticalSection that deadlocks. I also added some display commands to show you the details of the critical section in question. Now, if you look at what the display says you'll notice something odd: at first crit = 0x0011d1e0, but then it switches to 0x403112b8. And this is without any breakpoints having been set up within RtlEnterCriticalSection! So it can't be a context switch - it seems like a bug in the debugger. Or is this intentional in some way? Anyway, this critical section is the one the x11drv library sets up when XInitThreads is called. Next I attempted to find out where the main thread acquires the critical section, before the deadlock. This is attached as debugrun3. Notice that I worked around the odd debugger feature mentioned in the previous paragraph, by placing a breakpoint not at the entry point of RtlEnterCriticalSection, but a few next's later. This allowed me to add the condition crit==0x403112b8. The "crit" pointer seems to consistently stay the same between debugger sessions, so this works (for me at least). See how LockCount is 0, even though this is the first call to RtlEnterCriticalSection with crit==0x403112b8 during this session? It should be -1 for a critical section that is being acquired for the first time! So this made me suspect that the crit sect is acquired during initialization (and then not released), which is why I applied the following patch: Index: critsection.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/critsection.c,v retrieving revision 1.23 diff -u -r1.23 critsection.c --- critsection.c 5 Sep 2003 23:08:34 -0000 1.23 +++ critsection.c 4 Feb 2004 20:15:46 -0000 @@ -243,6 +243,7 @@ */ NTSTATUS WINAPI RtlEnterCriticalSection( RTL_CRITICAL_SECTION *crit ) { + if (crit==(RTL_CRITICAL_SECTION *)0x403112b8) TRACE("critsection=%p: LockCount=%ld\n", crit, crit->LockCount); if (interlocked_inc( &crit->LockCount )) { if (crit->OwningThread == (HANDLE)GetCurrentThreadId()) and then launched the debugger with: winedbg --debugmsg -all,+ntdll user32_test.exe.so (I didn't bother with making the reference to crit->LockCount thread-safe.) The result of this is attached as debugrun4. Notice this line: No debug information in ELF '/usr/X11R6/lib/libXrender.so.1' (0x40016000) See how after four calls to RtlEnterCriticalSection, LockCount starts to be 0? So a pretty good theory is that the critical section is acquired, and then not released, during the loading and initialization of /usr/X11R6/lib/libXrender.so.1. This theory is not bulletproof, which is why I attempted to see whether LockCount ever becomes -1 again, but the debugger consistently barfed on me (== crashed). Well, that's it for now - I'll let someone more knowledgeable in libraries and their initialization carry on with this, if the're interested. A final note: naturally, you most likely won't have the same address for the critical section as me, but you should be able to find out what it is if you redo the steps I made. Have fun! -- Sami

3 2

Re: Re: [Winecfg] - redo applications tab, misc changes
by chmorgan＠charter.net 05 Feb '04

05 Feb '04

> On February 4, 2004 05:20 pm, chmorgan(a)charter.net wrote: > > I'm pretty sure lots of other wine code uses 2 space indents, I know I > > started using them after working with wine. > > Yes, other code does so, but I think the preferred style is 4-space. > Now, as I said, if you feel strongly about it, it will stay 2-space. > But if you're flexible on this issue, 4-space indents would be nice. > > > No other comments on the ui changes in winecfg? ;-) I'll submit to > > wine-patches tonight after going through the code once more. > > Hey, I was at work (so I couldn't test). But now I got a chance to > look at it, so here are my comments: > -- it looks good. This is good stuff, I think we're getting > very close to the finish line. > -- have the Applications be the first page is a bit confusing. > This is advanced functionality, I'd start with something > else, like the Drives tab. > -- I could delete the "Global Settings" in the Application > tab, which also hosed my registry Doh. We should probably prevent users from deleting any of the global settings and ensure that the global settings are always present. > -- Whenever I've tried to add a app, and change it's settings, > it will disappear right away (whenever I tried to change > any of it's settings). > -- whenever I've tried changing something, I got errors like > this: > err:winecfg:setConfigValue Unable to set configuration key (null) in section AppDefaults\coolplayer.exe\Version to (null), res=1021 > Maybe my installation is faulty? > Winecfg is using the ~/.wine/config file right now, this isn't writeable so if you try to add/delete apps you won't be able to change anything. When you try to add the app the keys are created and then the treeview is completely rebuilt, I know, not the most efficent but it works. So, you click to add the app, the keys are created(but don't create since you can't modify your config file), and then the treeview is refreshed so your changes are lost. Chris

1 0

[ddraw] asynchronous screen updates
by Piotr Pawlow 05 Feb '04

05 Feb '04

If DGA is not available, Wine falls back to creating offscreen primary surface and blitting all changes to the screen. It knows which part of the surface might have changed by watching unlock calls. However, as Jukka Heinonen pointed out in his message posted on 17.10.2001, the update logic in asynchronous mode (when SYNC_UPDATE is not defined, which is the default) is broken: "(...)if more than one lock/unlock pair happens between update thread blits, display might not be updated correctly". Synchronous mode on the other hand, causes applications, which constantly lock and unlock big areas just to change a few pixels, run very slow. As this bug prevents me from playing "Warlords: Battlecry", I decided to do something about it. Here are my changes: - User_add_dirty_rect is now an asynchronous equivalent of User_copy_to_screen. It adds the rectangle to the list of dirty rectangles and signal the update thread that there is some work to do. - update thread calls User_get_dirty_rect to iterate over the list of dirty rectangles - current "naïve" algoritm keeps only one rectangle which is a union of all dirty rectangles, so it tends to redraw too much, but better algoritms may be implemented - removed now unused lastlockrect variable, and the code which updates it I attached the patch for your reviews, comments, suggestions. The game is almost playable now, there are remaining issues with DirectMusic (must be run with NODIRECTMUSIC switch or crashes) and windows managers (kwin cannot raise the window, metacity complains that the window attributes do not make sense). -- Piotr Pawlow mailto:pp@siedziba.pl

5 7

DIB_DirectDrawSurface_BltFast signed/unsigned comparision bug
by Piotr Pawlow 05 Feb '04

05 Feb '04

Hello, I spotted this bug while trying to fix mouse pointer trails problem in Warlords Battlecry. All widths, heights and left/top coordinates are of DWORD type, so substracting them from each other always give positive numbers. Thus h and w are always >= 0, so DDERR_INVALIDRECT is returned only in a couple of boundary cases. I just added explicit casting to int where needed. It didn't fix the mouse trails, but previously missing mouseover effect on icons at the main screen appeared, so I guess it is a change in the right direction :) Patch attached.

3 4

Broken tests in CVS
by Paul Millar 05 Feb '04

05 Feb '04

Hi everyone, It looks like last night's patches broke the conformance tests: http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php I'm away from my desk machines at the moment, so can't test this further. Does anyone else see these problems? Cheers, PS is winehq.org website dead at the moment? ---- Paul Millar

1 0

Re: Re: [Winecfg] - redo applications tab, misc changes
by chmorgan＠charter.net 05 Feb '04

05 Feb '04

I'm pretty sure lots of other wine code uses 2 space indents, I know I started using them after working with wine. No other comments on the ui changes in winecfg? ;-) I'll submit to wine-patches tonight after going through the code once more. The x11 tab is global settings only at this point. I think we can remove a couple of options on this tab, UseRandR is the only one I can think of atm. If we do make x11 settings per-app/global, like the apps and libraries tab, it seems like we should somehow combine the tabs. Yet is is nice having distinct tabs. In any case, I don't use per-app x11 settings so unless someone decides to implement this I likely won't be back at it for a while. Thanks, Chris > > From: "Dimitrie O. Paun" <dimi(a)intelliware.ca> > Date: 2004/02/04 Wed PM 02:14:59 EST > To: Chris Morgan <chmorgan(a)charter.net> > CC: wine-devel(a)winehq.com > Subject: Re: [Winecfg] - redo applications tab, misc changes > > On Tue, 3 Feb 2004, Chris Morgan wrote: > > > Comments, questions, suggestions welcome ;-) > > The one complaint I have is that it changes the 4-space indentation > to 2-space indentation, which makes the code so much harder to follow. > I know, you're doing the work, so you get to chose :), but if it's not > too much to ask, can we please stick to 4-space indentation? > > -- > Dimi. > >

6 6

Re: winedbg fixup
by Dmitry Timoshkov 05 Feb '04

05 Feb '04

"Eric Pouech" <pouech-eric(a)wanadoo.fr> wrote: > +static unsigned is_dt_flag_valid(unsigned d_tag) > +{ > +#ifndef DT_PROCNUM > +#define DT_PROCNUM 0 > +#endif > +#ifndef DT_EXTRANUM > +#define DT_PROCNUM 0 > +#endif Shouldn't in the latter case it be: #ifndef DT_EXTRANUM #define DT_EXTRANUM 0 #endif -- Dmitry.

1 0

Installing MS Windows Script 5.6
by Abdul-Haseeb Ahmad 04 Feb '04

04 Feb '04

Has anyone managed to intstall either the 9x or NT/XP version of windows script 5.6 (http://msdn.microsoft.com/library/default.asp?url=/downloads/list/webdev.as… I get an error registering the OCX wshom.ocx when it installs; I had to use a native MFC42.DLL to get vbscript.dll to register. I'm pretty sure I've narrowed down that this is the reason why I'm getting script errors in NHL2004; if you check EA's tech support site, it says that you need to install IE6SP1 (which i have installed) and Windows Script 5.6... oh this also was the 9x version that I tried to install... im thinking it might have to do with this specific error: fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 anyone know about this? heres the full error output: err:wave:OSS_WaveOutInit /dev/mixer1: No such device err:wave:OSS_WaveInInit /dev/mixer1: No such device fixme:setupapi:SETUPX_CreateStandardLDDs LDID_SRCPATH: what exactly do we have to do here ? fixme:setupapi:GenInstall16 unsupported flag: GENINSTALL_DO_REGSRCPATH fixme:setupapi:create_system_dirid unknown dirid 13 fixme:setupapi:vcpUICallbackProc16 (0x6e00, 0705, 0000, 00000000, 403210ac) - semi-stub fixme:setupapi:vcpUICallbackProc16 (0x6e00, 070f, 0000, 00000000, 403210ac) - semi-stub fixme:setupapi:vcpUICallbackProc16 (0x6e00, 0710, 0000, 00000000, 403210ac) - semi-stub fixme:setupapi:vcpUICallbackProc16 (0x6e00, 070b, 0000, 00000000, 403210ac) - semi-stub fixme:setupapi:vcpUICallbackProc16 (0x6e00, 070c, 0000, 00000000, 403210ac) - semi-stub fixme:setupapi:GenInstall16 unsupported flag: GENINSTALL_DO_CFGAUTO fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:MSFT_ReadValue BSTR length = 0? fixme:ole:MSFT_ReadValue BSTR length = 0? fixme:ole:MSFT_ReadValue BSTR length = 0? fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {0002e005-0000-0000-c000-000000000046}, hres is 0x80040154

1 1

Wine 0.9 TODO
by Dimitrie O. Paun 04 Feb '04

04 Feb '04

Hi folks, Here is the detailed TODO in all it's glory. We _really_ need to get this over with, so please help us out to get this release out the door. I'll mark names by the tasks based on conversations I had with folks at WineConf (and on the list). If you notice any mistakes, please let me know. Items marked with (???) have no owner. If you think you can help on any of these (including ones that do have owners!), please let me know. Help is needed and appreciated. If it's not clear what needs to be done for any of these, get in touch with me, I'll be more than happy to help you get started. Enjoy! A. WineHQ.org ============== 1. History page (Brian) [IN PROGRESS] 2. Testing status (Ferec) [IN PROGRESS] 3. I18n status (Vincent) [IN PROGRESS] 4. Porting status (Dimi, Steven) [IN PROGRESS] 5. Who's Who (Tom) 6. Documentation page update (???) 7. Download page (esp. source) needs work (???) 8. Acknowledgment page (???) 9. UI status update (???) 10. Integrate API status into WineHQ (???) B. Documentation ================ User Guide ---------- 1. Update configuration instructions based winecfg & regedit (???) 2. Suggest winefile instead of Calmira (???) 3. Misc cleanups (Dimi) Devel Guide ----------- 1. Update COM section/widl (???) 2. Redo Multimedia section (???) 3. Add i18n section (Vincent) 4. Suggest adding tests w/ patches (Dimi) 5. Cross compilation on RH (Michael) 6. Add section on KERNEL32 (???) 7. Misc cleanups (Dimi) Winelib Guide ------------- 1. Update around MinGW/winegcc (Dimi, Francois) 2. Misc updates (Dimi) C. Configuration ================ 1. Complete regedit (Attila) [IN PROGRESS] 2. Complete winecfg (Chris, Mike) 3. Setup API .inf scripts (Chris) [IN PROGRESS] D. UI Code ========== 1. Visible region handling in server (Alexandre) 2. Inter-process handle management (Urlich, Alexandre) E. File Formats =============== 1. .spec files [DONE] 2. .reg files [DONE] 3. I18n output (Vincent) [IN PROGRESS] F. Exported API =============== 1. DLL separation I [DONE] 2. DLL separation II (Alexandre, Eric) [IN PROGRESS] 3. wineserver protocol (Alexandre) G. Tools ======== 1. winebuild: build DLLs from .def files (Alexandre) 2. winegcc: add simple gcc-independence (Dimi) 3. winegcc: generate DLLs/-shared (Dimi) 5. winemaker: generate MinGW compatible makefiles (???) 4. winemaker: use dsw2make from MinGW (???) 5. winemaker: no configure script (???) 6. autoconf: add all Wine-specific macros to the aclocal (???) 7. winedesktop: create new tool (Alex) [IN PROGRESS] H. Miscellaneous ================ 1. Testing daemon to run as a Windows service (???) 2. Exec-shield support (???) 3. Prelink support (???) 4. Version symbols in libwine & libwine_unicode (Alexandre) 5. Find packager for a PE-build of Wine on SF (???) 6. Standardize Wine handling in autoconf (Dimi) -- Dimi.

3 5

Re: ntdll / kernel32: #49
by Dimitrie O. Paun 04 Feb '04

04 Feb '04

On Wed, 4 Feb 2004, Eric Pouech wrote: > that's all for now Ahhh, so disappointing! We were expecting a cool patch... :))) -- Dimi. P.S. Man, you rock! This is way, way cool!!!

1 0

[Winecfg] - redo applications tab, misc changes
by Chris Morgan 04 Feb '04

04 Feb '04

* programs/winecfg/En.rc, appdefaults.c, properties.c, properties.h, resource.h, winecfg.h, x11drvdlg.c, Es.rc, Pt.rc, Ru.rc, Si.rc Chris Morgan <cmorgan(a)alum.wpi.edu> Rename 'General tab' to 'About', move to the last position. Make applications tab handle global and per-app winver, dosver and winelook settings, mirroring the Libraries tab. Code copied from Robert van Herk's libraries tab. Move global/app specific function and global to the x11drv tab where it is currently used. Add a couple of property helper functions. Set 3D border around treeview controls. Removed invalid resources from languages other than En. Comments, questions, suggestions welcome ;-) Chris

2 1

Re: OLEPictureImpl_Load: fix for headerless pictures
by Fabian Cenedese 04 Feb '04

04 Feb '04

>> >> This fails on on my computer and I don't >> >> know how wine could detect if it's a headerless picture or no picture at all >> >> if they look the same (so far). >> > >> >Maybe check header[0] to be real .bmp or .gif magic and header[1] for >> >zero? >> >> I couldn't see a difference, always 0x746c in the first entry. > >Then what type of picture it is? > >0x4947 GIF >0xd8ff JPEG >0x4d42 BMP >0x0000 ICON >0x746c ??? Well, as I didn't use any pictures I don't know what it's supposed to be. Might as well be "NoPic" :) But I have also seen this marker where the second field was not zero. >Have you seen something like "Unknown magic, blah-blah-blah..."? It depends. Without your patch (where [0]=746c, and [1]=0) : trace:ole:OLEPictureImpl_Load (0x40383880,0x414de29c) fixme:ole:OLEPictureImpl_Load icon.idReserved=0 fixme:ole:OLEPictureImpl_Load icon.idType=0 fixme:ole:OLEPictureImpl_Load icon.idCount=0 fixme:ole:OLEPictureImpl_Load [0] width 0 fixme:ole:OLEPictureImpl_Load [0] height 0 fixme:ole:OLEPictureImpl_Load [0] bColorCount 0 fixme:ole:OLEPictureImpl_Load [0] bReserved 0 fixme:ole:OLEPictureImpl_Load [0] xHotspot 0 fixme:ole:OLEPictureImpl_Load [0] yHotspot 0 fixme:ole:OLEPictureImpl_Load [0] dwDIBSize 0 fixme:ole:OLEPictureImpl_Load [0] dwDIBOffset 0 fixme:ole:OLEPictureImpl_Load CreateIcon failed. (obviously when all data are 0) trace:ole:OLEPictureImpl_Release (0x40383880)->(ref=2) trace:ole:OLEPictureImpl_Release (0x40382ec8)->(ref=1) trace:ole:OLEPictureImpl_Destroy (0x40382ec8) trace:ole:OLEPictureImpl_Release (0x40383880)->(ref=1) trace:ole:OLEPictureImpl_Destroy (0x40383880) fixme:ole:OLEPictureImpl_Destroy Unsupported type 0 - unable to delete trace:ole:OLEPictureImpl_Release (0x40380a70)->(ref=1) trace:ole:OLEPictureImpl_Destroy (0x40380a70) trace:ole:OLEFontImpl_ReleaseHfont (0x4037f648)->(0xd82) (lock=0) trace:ole:OLEPictureImpl_Release (0x4037f7a8)->(ref=1) trace:ole:OLEPictureImpl_Destroy (0x4037f7a8) With your patch (already earlier with [0]=756c, [1]=...): fixme:ole:OLEPictureImpl_Load Could only read 109 of 2763 bytes in no-header case? fixme:ole:OLEPictureImpl_Load Unknown magic 746c, 109 read bytes: 6c 74 00 00 00 00 00 00 6c 74 00 00 00 00 00 00 00 00 01 00 00 00 0a 00 54 00 61 00 62 00 20 00 31 00 01 00 00 00 04 52 e3 0b 91 8f ce 11 9d e3 00 aa 00 4b b8 51 6c 74 00 00 00 00 00 00 00 00 00 00 00 00 0a 00 54 00 61 00 62 00 20 00 32 00 01 00 00 00 04 52 e3 0b 91 8f ce 11 9d e3 00 aa 00 4b b8 51 6c 74 00 00 00 00 00 00 00 00 00 00 00 00 ff 02 04 Maybe this isn't even part of a picture and we shouldn't be reading this. How does it know that a picture is coming? Perhaps we shouldn't even enter OLEPictureImpl_Load if there is no picture at all. Thanks bye Fabi

2 1

Orkut community for wine
by Shachar Shemesh 04 Feb '04

04 Feb '04

Hi all, Just so noone else create another community, I have created an Orkut community for Wine. It's located at http://www.orkut.com/Community.aspx?cmm=8767. Sorry about the noise. Shachar -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/

1 0

Mouse up vs Mouse click
by Fabian Cenedese 04 Feb '04

04 Feb '04

Hi Where is decided if I release the mouse button if a mouse up or a mouse click is generated? Is this time dependent? Or generally the same? The misbehaving app uses a ownerdrawn, CListCtrl-derived list. When I click on a cell not in the first column the cell gets selected. But on wine I can see that the selection flashes shortly and disappears right again (Surprisingly it works when I click in the first column. As my application uses the same code for all columns it must be something else.). After putting some debug messages in my code I found that on Windows after the left-button-down event a left-button-click event is generated, no matter how long I hold the button before releasing. On wine there is no click event but a mouse up event. And the cell flashes even when I hold the button, so it's not the releasing itself that clears the selection. The control is a bit quirky with moving focus around and handling events specially. But still it works on Windows :) Now I'm a bit lost how I can debug this. +mouse didn't show anything usefull. I guess the generating and sending of the events is done in the wineserver. Thankful for any hints. bye Fabi

6 22

PPDEV: Allow to switch direction of the printer port
by Uwe Bonnes 04 Feb '04

04 Feb '04

Changelog: dlls/winedos/ppdev.c:IO_pp_outp Allow to switch direction of the printer port This lets mitoujtag.exe access the Jtag chain via the parallel port and a Xilinx parallel cable. -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: wine/dlls/winedos/ppdev.c =================================================================== RCS file: /home/wine/wine/dlls/winedos/ppdev.c,v retrieving revision 1.1 diff -u -w -r1.1 ppdev.c --- wine/dlls/winedos/ppdev.c 17 Sep 2003 22:45:46 -0000 1.1 +++ wine/dlls/winedos/ppdev.c 4 Feb 2004 15:27:00 -0000 @@ -300,7 +300,16 @@ case 0: return IO_pp_do_access(idx,PPWDATA,res); case 2: - return IO_pp_do_access(idx,PPWCONTROL,res); + { + /* We can't switch port direction via PPWCONTROL, + so do it via PPDATADIR + */ + DWORD mode = *res & 0x20; + IO_pp_do_access(idx,PPDATADIR,&mode); + mode = (*res & ~0x20); + return IO_pp_do_access(idx,PPWCONTROL,&mode); + } + case 1: case 0x400: case 0x402:

1 0

Unable to compile under FreeBSD 4.8
by CyberBotX 04 Feb '04

04 Feb '04

I've been trying to compile the latest version of WINE (1-21-2004) under FreeBSD 4.8-RELEASE, but it keeps failing on me with the following during the compile of glu32: gcc -shared -Wl,-Bsymbolic,-z,defs,-init,__wine_spec_init,-fini,__wine_spec_ fini glu32.spec.o glu.o glu32.dll.dbg.o -o glu32.dll.so -L../../dlls -L../../libs/wine -lwine -L/usr/X11R6/lib -lSM -l ICE -lXxf86dga -lXxf86vm -lXrandr -lXrender -lXv -lXext -lX11 -lGL -lGLU -L ../../libs/port -lwine_port -lm -lc /usr/lib/libgcc.a(_eh.o): In function `__empty': _eh.o(.text+0x9e): undefined reference to `pthread_setspecific' /usr/lib/libgcc.a(_eh.o): In function `__get_eh_info': _eh.o(.text+0xec): undefined reference to `pthread_key_create' _eh.o(.text+0x1b9): undefined reference to `pthread_getspecific' _eh.o(.text+0x1d8): undefined reference to `pthread_setspecific' /usr/lib/libgcc.a(frame.o)(.text+0x44b): undefined reference to `pthread_mutex_lock' /usr/lib/libgcc.a(frame.o)(.text+0x492): undefined reference to `pthread_mutex_unlock' /usr/lib/libgcc.a(frame.o): In function `__register_frame_info': frame.o(.text+0x8d9): undefined reference to `pthread_mutex_lock' frame.o(.text+0x900): undefined reference to `pthread_mutex_unlock' /usr/lib/libgcc.a(frame.o): In function `__register_frame_info_table': frame.o(.text+0x969): undefined reference to `pthread_mutex_lock' frame.o(.text+0x990): undefined reference to `pthread_mutex_unlock' /usr/lib/libgcc.a(frame.o): In function `__deregister_frame_info': frame.o(.text+0x9dc): undefined reference to `pthread_mutex_lock' frame.o(.text+0xa27): undefined reference to `pthread_mutex_unlock' frame.o(.text+0xa4d): undefined reference to `pthread_mutex_unlock' *** Error code 1 Stop in /usr/home/cyberbotx/wine/dlls/glu32. *** Error code 1 Stop in /usr/home/cyberbotx/wine/dlls. *** Error code 1 Stop in /usr/home/cyberbotx/wine. I don't know if there is a way to stop it from doing that, but I was told it'd be best to let you guys know. I was trying to compile the source because I've been having problems with the ported version from FreeBSD's site. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.564 / Virus Database: 356 - Release Date: 1/22/2004

1 0

Re: Wineconf wrapup
by Brian Vincent (C) 04 Feb '04

04 Feb '04

> Say, I wanted to thank everyone for coming to Wineconf 2004; > as far as I can tell, a good time was had by all, and we may > even have accomplished one or two useful things <grin>. fyi, I posted a summary in the form of a WWN issue: http://www.winehq.com/?issue=208 If anyone sees any glaring errors or omissions let me know. -brian

1 0

NHL2004 having problems with OLE?; Error output
by Abdul-Haseeb Ahmad 04 Feb '04

04 Feb '04

Okay, so I'm running wine cvs from Feb3 - IE6 installed (installed it on wine20031212 via mike hearn's script and then just used that directory for winecvs) - NHL2004 Demo installed (ftp://ftp.ea.com/pub/easports/demos/nhl2004/NHL2004Demo.exe) & Full version installed - following settings: [AppDefaults\\nhldemo.exe\\Version] "Windows" = "win98" [AppDefaults\\nhldemo.exe\\DllOverrides] "ole32" = "native, builtin" "oleaut32" = "native, builtin" "mshtml" = "native, builtin" "shfolder" = "native, builtin" "shell32" = "native, builtin" "shell" = "native, builtin" "shdocvw" = "native, builtin" "shlwapi" = "native, builtin" "urlmon" = "native, builtin" "crypt32" = "native, builtin" "wininet" = "native, builtin" - ole32, oleaut32 copied from win98 installation, stdole2.tlb from winxp install http://bugs.winehq.org/show_bug.cgi?id=1970 okay, so I can get into the menus with those settings.. ole32/oleaut32 being native reduce the error messages that I get and in the full version lets me navigate around more of the menus.. but I still get some js/html errors.. seems like the HTML files can't read the "global" variables and functions.. im not exactly sure whats going on, i've attached (at http://bugs.winehq.org/show_bug.cgi?id=1970): 1)intro.html which skips the intro videos so you dont get a crash 2)running wine --debugmsg +ole nhldemo (exiting the game as soon as i get into the menus) 3)running winedbg nhldemo, and entering cont a few times until i get into the menu, where i start to get a lot of errors related to the DllUnregisterServer function in the NHL2004 Browser Controls DLL... im hoping someone can help me narrow down the problems here, thanks

1 0

Wineconf wrapup
by Jeremy White 03 Feb '04

03 Feb '04

Hi all, Say, I wanted to thank everyone for coming to Wineconf 2004; as far as I can tell, a good time was had by all, and we may even have accomplished one or two useful things <grin>. I really appreciate that so many of you braved -30C temperature and two days of constant snowfall to come work with us on Wine - such insanity^H^H^H^H^H^H^H^H dedication is admirable. I wanted to suggest that we get to planning Wineconf 2005 sooner rather than later; I'm curious to see which European city hosts the event <grin>. For the record, we're willing to be the major sponsor for the next Wineconf; we'll kick in some funds and person power to help make sure it happens. However, I think it'll only work well in conjunction with one or more locals. I did have some closing thoughts and advice I wanted to get off my chest; there are some things I would do differently next time, and it's probably also wise to touch on the things that worked well. In no particular order, here are a number of thoughts: 1. Screw fancy audio/video streaming. Find an inexpensive telephone conference service, and use it. Test it, several weeks in advance, *with the intended audience* (the stream worked fine on this side of the Atlantic, afaict), and *with the expected load*. Our tests were always done with less load than we had during wineconf, because the streaming traffic used the same pipe as the 'net connection everyone was using. We wasted a lot of time and energy on this, against my initial better judgement, and it proved to be largely useless, afaict from the #wineconf comments. Go low tech. Swallow your geek pride. Just get simple audio that works. /me kicks self 2. Things that worked well: A. An inexpensive location Not one person opted for the expensive hotel I listed; cost really matters to this crowd. The last thing we want to do is scare away young people; they often have enormous energy and no cash. Help with hostels and friends with floors was appreciated. B. Breaks The only times that I was sure that productive conversations were occuring was during the breaks. Provide lots of 'em. Go very light on scheduled topics. C. Do lunch in; that worked really well. Have lots of food and beverages about, that also seems to work well. Bring the water cooler down on the *first* day <grin>. D. Internet connectivity is a must. Really. And provide both wireless and wired. We had some grumpy campers when we initially didn't have enough cat5 ports. E. All of the professional conference paraphenalia was invaluable. A wireless mic (preferably two) and someone to operate it. A PA type system. A projector. Even with the relatively small group we had it was invaluable. 3. Suggestion - blue collar location I know it's fashionable to suggest fancy vacation spots for Wineconf 2005, but I honestly think it would be much better to pick a 'blue collar' venue. Pick somewhere that is a transportation hub, with modest prices. Someplace where some Wine hackers live; having local help is incredibly valuable (thanks to Mandi, Chris, Jon, Aric, Zak, Newman, and all of the gang who did so much work). In fact, when we did go to the fancy tourist night spot, we ended up at a bar where it was too loud to talk; conversation amongst folks from 10 different countries is hard enough without load blaring music or odd ball distractions. A quite room and a good supply of ale, perhaps with a whiteboard, is what folks mostly craved. This is just my $0.02; I think others would differ sharply. 4. The final, critical piece of advice Don't type 'ifconfig eth0 down' in a terminal Window on the Mac in an attempt to reinitialize it's DHCP settings, unless you're dead certain you haven't ssh'd over to the server that is the life blood of your community, and is physically miles away behind locked doors... ...and I still can't figure out why Alexandre won't take my patches! <grin> At any rate, I feel much better now - thanks for listening, and thanks for coming. Cheers, Jeremy

2 1

status of journal hook chain work
by Bill Medland 03 Feb '04

03 Feb '04

I've just tripped over the fact that the journal hook chains are currently not implemented (and were disconnected in October 2002). Does anyone have any plans to do anything about them? -- Bill Medland mailto:billmedland@mercuryspeed.com http://webhome.idirect.com/~kbmed

1 0

shlwapi.MLIsMLHInstance
by Juan Lang 03 Feb '04

03 Feb '04

Anyone know anything about this function? I stubbed it to get around an occasional crash in native common controls, but I'm not positive the function signature's correct. --Juan __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/

1 0

Re: OLEPictureImpl_Load: fix for headerless pictures
by Fabian Cenedese 03 Feb '04

03 Feb '04

>> >In my case there are lots of *.bmp (with picture) with exactly same header >> >i mentioned. Thus header[1]==0 doesnt imply 'there is no picture at all' >> > >> >This pictures came in ole storage taken from a real win32 app, and loading >> >them on windows works correctly. >> >> Do you have VB6? Can you create a testprogram? If not then I can send you one. >> Just create an empty form and place the SSTab on it (the one from tab control, >> not the one in the standard palette). >I don't have VB. In fact i ether dont have VC and windows installed at all >here. > >If you have an winelib based example, let's try get it working. It's not a winelib app but I can send you the exe and ocx off the list. >> This fails on on my computer and I don't >> know how wine could detect if it's a headerless picture or no picture at all >> if they look the same (so far). > >Maybe check header[0] to be real .bmp or .gif magic and header[1] for >zero? I couldn't see a difference, always 0x746c in the first entry. bye Fabi

2 1

Re: OLEPictureImpl_Load: fix for headerless pictures
by Fabian Cenedese 03 Feb '04

03 Feb '04

>> I don't think that this is correct. If header[1] is 0 then it means that there is no picture at >> all, and not a picture without header (me thinks). When trying to start a program that uses >> the SSTab from TabCtl32.ocx without having assigned icons to the tabs it fails because >> wine tries to create icons that aren't in the stream. So there's no point in continuing and trying >> to read data from the stream. I could only make it work when I jump out of this function >> without doing anything if header[1] is 0. That may be wrong too but this patch doesn't >> solve it either. > >In my case there are lots of *.bmp (with picture) with exactly same header >i mentioned. Thus header[1]==0 doesnt imply 'there is no picture at all' > >This pictures came in ole storage taken from a real win32 app, and loading >them on windows works correctly. Do you have VB6? Can you create a testprogram? If not then I can send you one. Just create an empty form and place the SSTab on it (the one from tab control, not the one in the standard palette). This fails on on my computer and I don't know how wine could detect if it's a headerless picture or no picture at all if they look the same (so far). Thanks bye Fabi

2 1

Re: OLEPictureImpl_Load: fix for headerless pictures
by Fabian Cenedese 03 Feb '04

03 Feb '04

>Hi, >In my case headerless bitmaps have >{ 0x42, 0x4d, 0x9c, 0xbd, 0x00, 0x00, 0x00, 0x00 } first 8 bytes. > >So, when last four are equal to zero its 'no header' case. > >ChangeLog: > OLEPictureImpl_Load: fix for headerless pictures > >Index: dlls/oleaut32/olepicture.c >=================================================================== >RCS file: /home/wine/wine/dlls/oleaut32/olepicture.c,v >retrieving revision 1.30 >diff -u -r1.30 olepicture.c >--- dlls/oleaut32/olepicture.c 5 Sep 2003 23:08:33 -0000 1.30 >+++ dlls/oleaut32/olepicture.c 1 Feb 2004 12:35:41 -0000 >@@ -875,7 +875,7 @@ > FIXME("Failure while reading picture header (hr is %lx, nread is %ld).\n",hr,xread); > return hr; > } >- if (header[1] > statstg.cbSize.QuadPart) {/* Incorrect header, assume none. */ >+ if (header[1] > statstg.cbSize.QuadPart || (header[1]==0)) {/* Incorrect header, assume none. */ > xread = 8; > xbuf = This->data = HeapAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,statstg.cbSize.QuadPart); > memcpy(xbuf,&header,8); I don't think that this is correct. If header[1] is 0 then it means that there is no picture at all, and not a picture without header (me thinks). When trying to start a program that uses the SSTab from TabCtl32.ocx without having assigned icons to the tabs it fails because wine tries to create icons that aren't in the stream. So there's no point in continuing and trying to read data from the stream. I could only make it work when I jump out of this function without doing anything if header[1] is 0. That may be wrong too but this patch doesn't solve it either. Described here: http://www.winehq.org/hypermail/wine-devel/2004/01/0968.html bye Fabi

2 1

Re: Sourceforge WIne RPMs and Yum
by Dwayne Bailey 03 Feb '04

03 Feb '04

Hi, Are there any yum experts here? I thought it would be a good idea to get a yum repository established for the Wine RPMs held at sourceforge. I for one would love to have the latest build of wine installed as soon as RPMs are available on Sourceforge. yum-arch seems to be the command to create the repository headers but I'm not sure how you would manage this with the round robbin sourceforge downloads. I think some other sf project have managed this. Anyone out their who can help? Dimitrie O. Paun wrote: >On February 3, 2004 04:42 am, you wrote: > > >>I was wondering if it would be possible to create yum repositories >>of the Sourceforge RPMs certainly for use with Fedora. >> >> > >It sounds like a really good idea, but I know little about the topic, >as I'm not yet running Fedora. You may want to post a call for >volunteers on wine-devel(a)winehq.org, maybe someone has the know-how >and steps forward... > > > -- Kind regards Dwayne Bailey dwayne(a)translate.org.za +27-21-448 7827 / 9265 (work) +27-21-448 9574 (fax) +27-83-443 7114 (cell) "An English-only, or even an English-mainly, policy necessarily condemns most people, and thus the country as a whole, to a permanent state of mediocrity, since people are unable to be spontaneous, creative and self-confident if they cannot use their first language" Dr Neville Alexander - 'Where English can Serve but not Empower.' Translate.org.za - Opensource software for all South Africans A project of the Zuza Software Foundation Zuza - given freely, get as a gift, obtained freely

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel