- Wine-Devel - list.winehq.org

Re: RPCRT4: reimplement UuidCreate() with Win32 APIs (resubmit)
by Alexandre Julliard April 27, 2004

April 27, 2004

Hans Leidekker <hans(a)it.vu.nl> writes: > Anything wrong with this one? > > Changelog: > Reimplement UuidCreate() with Win32 APIs. I don't think rpcrt4 should depend on iphlpapi, it doesn't on Windows AFAICS. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: 2 Fatal Problems With Winesetuptk-0.73 (BOTH Sourceforge Release Formats)
by Ivan Leo Murray-Smith April 27, 2004

April 27, 2004

If you build a binary for older versions of Linux, let me know and I'll put your binary on the sourceforge page. AFAIK winesetuptk will only work correctly with the itcl/tck libs shiped in the tarball. Ivan.

1 0

Winsock help...
by António Serra April 27, 2004

April 27, 2004

Hi all! I'm porting a windows application to Linux using the winelib. I created a project with KDevelop and include all ( at least I think all ) the .dll.so needed by my project. After compiling a linker error message appears, saying that /windows/D/ HICOD2000/j2kserver/j2kserver/kdu_server.cpp:2894: undefined reference to `WSAWaitForMultipleEvents' . It happens that I included the ws2_32.dll.so in my project. Am I missing something? TIA -- ______________________ António Serra aserra.wine(a)iol.pt ______________________

2 1

Re: GetTimeZoneInformation patch
by Rein Klazes April 27, 2004

April 27, 2004

On Tue, 27 Apr 2004 10:03:13 -0400, you wrote: > I was looking through the source code and noticed a FIXME for the > GetTimeZoneInformation API in dlls/kernel/time.c saying that the function > needed to return a different value if Daylight Savings Time was in effect. I > implemented that feature, and also made the function return the proper value > if DST was not in effect for the version being simulated. > > I have enclosed the patch for the file against the latest source package. > > Here is the ChangeLog entry (I didn't patch the ChangeLog file): > > * dlls/kernel/time.c > William Lahti <computerman413(a)ezrs.com> > > - Fixed return values in GetTimeZoneInformation Three remarks: - you are using ftime() of which my man page says: | These days the contents of the timezone and dstflag fields are undefined. and | This function is obsolete. Don't use it. Have a look at the implementation of GetDaylightFlag() or use it directly. - You state that on NT, 2K and XP the return code is TIME_ZONE_ID_UNKNOWN when the daylight saving time is not in effect. This is only true if the transition dates are undefined. This is true in the current implementation, but those transition dates are a bigger FIXME then the correct return value. - I am not sure if it is worth the trouble to be so correct for windows 9x. The NT return value is not impossible under win9x and unless there is an application that depends on it, Wine defaults to the NT behavior. Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

Re: MDI fix attempt
by Dmitry Timoshkov April 27, 2004

April 27, 2004

"Krzysztof Foltman" <kfoltman(a)portal.onet.pl> wrote: > Applying this patch makes MDI Window menu behave as follows: > > - if no child windows are present, no separator is added (or it is > removed if it was present before) > - if any child windows are present (and visible), a separator is added > after last item of the original Window menu (unless it was already there) Is there a real bug you are trying to fix? When I last time worked with MDI code including Window menu handling I did a lot of tests under Windows. Did you? -- Dmitry.

2 6

Re: Winetest: outstanding issues (USING)
by Dimitrie O. Paun April 27, 2004

April 27, 2004

Now for the second installment: USING (Feri) ----------------------- A. winetest Winetest will have to support a new option -B <filename> This will add a new section to the report, just before the test results, called "Build Info". The body of this section will be read from <filename>, with each time indented (say 4 spaces), and a blank line to end it (for neatness). B. Dissect & gather Need only recognize the "Build Info" section as optional, and ignore it for now. Maybe dissect should do that as a rule, ignore sections it doesn't understand. This way we can easily add more data in the future, without needing to constantly patch dissect. Such sections would have all lines indented, and would end with a blank line. BTW Feri, can we indent the body of our current sections? Would that break stuff? It would be nice to, would make the report more readable. We should be more forgiving with the parsing, like HTML is. The idea would be: "we should look only for stuff that we need for the report, additional stuff should be ignored. Moreover, non-essential stuff should be optional, and if not present/parsed, don't display". -- Dimi.

4 8

Fwd: Re:SpecOpS Labs
by Ivan Leo Murray-Smith April 27, 2004

April 27, 2004

I asked project davied if they know what use of LGPL code involves, and if the're using wine code, I got the following answer. The impression I have is that they are using major parts of wine. They claim they will fully comply with the LGPL. Here is the full email they sent me. > Good Evening Mr. Smith > > > Thanks for your email; We appreciate your taking the time to delve into > Project David. We feel certain that the closer that you look at the project > the more comfortable you will be with it. > > Our overall purpose of the project is to encourage consumers to use Linux. > Our David Linux/Win Bridge software is simply a product to facilitate the > transition to Linux. Our Linux/Win Bridge software is one of multiple > components, which comprise our OS platform. In the future we will release > another component, which is a set of tools that will encourage developers to > write native Linux applications. > > The David software is a joint development effort between De La Salle > University and SpecOpS Labs. Our Chief Technical Officer is Mr. Peter > Valdez. As you may know Mr. Valdez is the founder of Tivoli Systems, which > is now a multi billion-dollar flagship product of IBM. > > The code for our Windows/Linux Bridge is a hybrid of code, including our own > proprietary code, and code from several open source projects. For now we > are keeping the exact nature of our code under wraps until our first release > of David. We are not using pirated or stolen code from Microsoft or any > other source. As stated we are not disclosing the nature of our code or our > exact methodology for running Windows Apps on Linux, this is for competitive > and other reasons. However, a good deal of our success is attributed to our > innovative methodology in assembling together open source code, proprietary > code that we have written/purchased, and freeware. In the future, once we > disclose how we have done this, then Im sure a number of developers will be > kicking themselves in the rear end for not having thought of this > themselves. > > We do encourage the open source movement and we will comply with the GNU > LESSER GENERAL PUBLIC LICENSE. > > Our website is currently under construction, the data (*especially the > technical data) on the website for the most part is not current and in some > cases is up to 20+ months old. We are now in the process of doing a major > overhaul of the site, which we expect to be completed in a few weeks. *The > technical data on our web site concerning David, is outdated and in some > cases a competitive smoke screen. We appreciate your comments on the WINE > Project and we have no intention of misrepresenting the WINE. Therefore, we > are now consulting our English-technical writers and the Filipino - > designers/developers of David to ensure that there are no mistakes in the > translation. Until we can update the website we have disabled the links to > both our technical and competitive data. Hopefully, the development > community wont get wrapped around the axle about David, and will withhold > judgment until David is released. > > So far as our product goes we just completed our prototype, which has been > in the making for quite some time. Our first release will be issued before > the end of 2004; we expect to start Beta Testing in about 4-5 months. On 22 > April we held a press conference at De La Salle University. During the press > conference we demonstrated our prototype to more than 30 members of the > local and international media. During the demo we ran Macromedia Flash, and > MS Office on our Windows/Linux Bridge without a hitch. What you read in the > media was primarily the result of the press conference/demo. David is not a > hoax or vaporware, but we're not going to make any further claims about > David at this point, We prefer to let our software do our talking for us. > > > FYI: We are now a publicly traded company, our ticker symbol is SPLMF, you > can view it on any major financial website such as Merrill Lynch: > http://askmerrill.ml.com/markets_chart/1,2260,,00.html?q=SPLMF > > > > Thanks > > > > > Customer Service > SpecOpS Labs > Summit One Office Tower > Unit 23-H, 530 Shaw Blvd > Mandaluyong City, Metro Manila, Philippines > > Office 63 2 532-7854 > Fax 63 2 532-5875 >

7 10

winealsa fails the winmm test
by Francois Gouget April 27, 2004

April 27, 2004

I'm not having much luck with sound this week-end :-( First there was the crash in ALSA_WaveInit() (an old bug apparently), but now the winmm test either gets stuck or crashes. When it gets stuck it's because I get: trace:wave:wodUpdatePlayedTotal dwPlayedTotal=21987 dwWrittenTotal=22050 delay=63 trace:wave:wodPlayer_NotifyCompletions still playing 0x4069fd1c (22050/21987) trace:wave:wodPlayer waiting 2ms (7,2) trace:wave:wodUpdatePlayedTotal dwPlayedTotal=21987 dwWrittenTotal=22050 delay=63 ... So the problem is that everything has been played but because snd_pcm_delay() keeps returning 63, dwPlayedTotal never reaches the 22050 that would signal the completion of the first tone. Now it seems like snd_pcm_delay() should return 0 after a while so this looks like an Alsa bug (0.9.6). Is this a known bug? Is there a way to work around it? (besides commenting out the call to snd_pcm_delay()) And when I don't get into the above infinite loop it's because I've crashed before with an Alsa assertion: trace:wave:wodPlayer waiting 7ms (7,4294967295) trace:wave:wodUpdatePlayedTotal dwPlayedTotal=11781 dwWrittenTotal=17184 delay=5403 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4069fd1c.17184[22050] trace:wave:wodPlayer_WriteMaxFrags 1065 dwLength=2433 toWrite=110 0010:Call ntdll.RtlAcquireResourceShared(4037c168,00000001) ret=404e0751 0010:Ret ntdll.RtlAcquireResourceShared() retval=00000001 ret=404e0751 0010:Call ntdll.RtlReleaseResource(4037c168) ret=404e08ae 0010:Ret ntdll.RtlReleaseResource() retval=00000000 ret=404e08ae 0010:Call ntdll.RtlTryEnterCriticalSection(40340098) ret=404e0519 0010:Ret ntdll.RtlTryEnterCriticalSection() retval=00000001 ret=404e0519 0010:Call ntdll.RtlTryEnterCriticalSection(40340098) ret=404e0519 0010:Ret ntdll.RtlTryEnterCriticalSection() retval=00000001 ret=404e0519 0010:Call ntdll.RtlTryEnterCriticalSection(40340098) ret=404e0519 0010:Ret ntdll.RtlTryEnterCriticalSection() retval=00000001 ret=404e0519 wine-kthread: pcm.c:5899: snd_pcm_mmap_commit: Assertion `frames <= snd_pcm_mmap_avail(pcm)' failed. The interesting things are that wwo->write points to snd_pcm_mmap_writei(). This assertion would seem to imply that we are writing too much stuff at once? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement.

2 1

2 Fatal Problems With Winesetuptk-0.73 (BOTH Sourceforge Release Formats)
by Kenny Love April 27, 2004

April 27, 2004

In the Bugzilla system, including the search page, there is no mention of Winesetuptk, so I can't tell whether the following bugs are new to you. These two problems are of considerable import to aspiring Wine users, particularly if they are running Red Hat Linux 6.2 or equivalent or older (for the first item, Red Hat Linux 7.x or equivalent might also be affected). 1. The rpm'ed Winesetuptk binary currently posted on the Sourceforge site, winesetuptk-0-73.i586.rpm, aborts on startup on a Red Hat Linux 6.2 system with the message "winesetuptk: /lib/libc.so.6: version `GLIBC_2.3' not found (required by winesetuptk)". I suspect this means that the binary (maybe the Tcl/Tk/ITcl) is dynamically linked to glibc 2.3, but Red Hat Linux 6.2 can only be easily upgraded to glibc 2.1.3-21; even Red Hat Linux 7.3 easily upgrades only to glibc 2.2.5-44, so this might prohibit most Red Hat Linux installations older than 8.0 from running this binary. 2. The scripts in the Winesetuptk tarball currently posted on the Sourceforge site, /winesetuptk-0-73.tar.bz2, hang. When run "as scripts directly" on a Red Hat Linux 6.2 system with Tcl 8.0.5-35 and ITcl 3.0.1-35 installed, after the program opens a window stating "Autodetection in Progress", an error notice appears stating that map is not a legal argument to the string function ("Error: bad option "map": must be compare, first, index,"...). After the notice's "Ok" button is pressed, the error notice box disappears, but the program quietly hangs, ignoring attempts to close the remaining windows. Bash's kill command, probably unknown to the novice, is required to exit the comatose program. Also, on the launching shell window appears the message "CBase::AutoConf:GetWinInstalls: unable to grep /dos/c/msdos.sys: child process exited abnormally ". My /dos/c/ directory contains my dual-boot Windows 3.1 system. In the tcl8.3.2 subdirectory, the "changes" file lists, between the "8.1 final" and "8.1.1" headers, a "new features" entry dated 5/3/99 mentioning adding Jeff Hobbs' patches introducing, among others, a map argument to the string function. The Sourceforge Winesetuptk-0.73 release note states that at version 0.34b, all was successfully converted from requiring Tcl 8.4 to using Tcl 8.0, so this map call appears to be a small overlooked mouse with a show-stopping roar. I lack Tcl programming experience, but the stack trace (see below) and 'grep'-ing the source tree for potential "string_ map" calls seems to implicate "winesetuptk-0.73/Enable8.0Compatibility.tcl", line 42 as the culprit; it looks like there's no if-clause to handle $aCmd == "map". Here's the stack trace: bad option "map": must be compare, first, index, last, length, match, range, tolower, toupper, trim, trimleft, trimright, wordend, or wordstart while executing "string_ map {{${WinDir}} windows} {${WinDir}/system}" ("eval" body line 1) invoked from within "eval string_ $aCmd [list $aStr] $args" (procedure "string" line 26) invoked from within "string map [list {${WinDir}} $WinDir] $SystemDir" (object "::ObjBase" method "::CBase::AutoConf:GetWinInstalls" body line 74) invoked from within "AutoConf:GetWinInstalls $Drives" (object "::ObjBase" method "::CBase::AutoConf" body line 39) invoked from within "$pObjBase AutoConf" ("GEN_NEW" arm line 6) invoked from within "switch [$pObjBase AccessCfgData GET_KEY_VALUE_BY_NAME Cfg WhatToDo] { GEN_NEW { CMsgDialog ObjWaitMsg . .wait_msg "WineSetup" "Autodetection..." (object "::ObjScrFileLoc" method "::CScrFileLoc::SetWineData" body line 2) invoked from within "SetWineData" (object "::ObjScrFileLoc" method "::CScrFileLoc::SetResult" body line 58) invoked from within "::ObjScrFileLoc SetResult NEXT" (in namespace inscope "::CBaseScr" script line 1) invoked from within "namespace inscope ::CBaseScr {::ObjScrFileLoc SetResult NEXT}" invoked from within ".f_scr.b_next invoke" ("uplevel" body line 1) invoked from within "uplevel #0 [list $w invoke]" (procedure "tkButtonUp" line 8) invoked from within "tkButtonUp .f_scr.b_next" (command bound to event) I'm going to try compiling the Winesetuptk-0.73 source from the tarball on my system; hopefully that will produce a >working< binary dynamically linked to glibc 2.1.3-21. Considering that most aspiring Wine users, (Remember: Many, perhaps most of those are new to Linux itself.), are currently steered by the Wine documentation to use the Winesetuptk program with its nice, friendly GUI, those who took the time-honored route of putting a Linux installation from second-hand CD's on an older, expendable PC (which often limits one to a 6.2/7.0 version or less because 2.4 kernels can thrash too much on old hardware to be useful) may be in for a big suprise when they try to graphically configure their wine.conf file. To summarize, the rpm binary release as-is probably won't start for Linux versions older than Red Hat Linux 8.0 or equivalent and the tarball release as-is hangs deviously when run "as scripts directly" on systems with Tcl 8.0, possibly 8.1.0. By the way, that rpm should have refused to install because the program required a higher version glibc than my Linux system possesses, shouldn't it? Thanks! Kenny A life spent making mistakes is not only more honorable, but more useful than a life spent doing nothing. G. B. Shaw

1 0

Alignment testing
by Hans Leidekker April 27, 2004

April 27, 2004

Hi, kernel/tests/generated.c currently shows one failure when the executable is compiled with MinGW. Investigation shows that MinGW and GCC differ when it comes to alignment of doubles (i.e. a 64 bit wide type). I have constructed the test below that shows the difference between MinGW and GCC. My question is, could someone compile this with MSVC >= 6, run it, and report the outcome here? Thanks, -Hans

3 4