- Wine-Devel - list.winehq.org

Re: wine on Intel Xeon processor
by Tom Spear (Dustin Booker, Dustin Navea) Feb. 11, 2006

Feb. 11, 2006

Hi, sorry I didnt reply all so it would go to the wine list. Is your Xeon a dual core, or possibly even 64-bit? I doubt that 64-bit compared to 32-bit would make a difference, but if the Xeon is a dc, it might, as I recall another thread here saying that they were having problems with a dual core system being slower. The only other thing I can think of (of course I'm not that far along with my programming skill, and I doubt it will make much difference anyway) is what kind of machine the application and the dll were compiled on. If you have the source for either of those, and have access to a xeon that is running windows (2003 server?) and can compile, i'd suggest trying that, otherwise, I have no clue. HTH Tom Ananth M wrote: > > > On 2/10/06, *Ananth M* <mekaananth(a)gmail.com > <mailto:mekaananth(a)gmail.com>> wrote: > > The wine source code was compiled in the Xeon processor > > We had'nt recompiled the kernel with Xeon Processor , we are using > the same that is coming with RHEL 4.0 > > > > Now I compiled the kernel again and used the new kernel Image. > Still I am getting the same timings > > > > On 2/9/06, *Tom Spear (Dustin Booker, Dustin Navea)* < > speeddymon(a)gmail.com <mailto:speeddymon(a)gmail.com>> wrote: > > Are the wine binaries on the Xeon server precompiled (even > copied from > the P4 machine), or are they compiled on the Xeon server itself? > > Also, has the kernel been recompiled with explicit support for > the Xeon, > or is it the stock kernel that comes with RHEL 4? > > Tom > > Ananth M wrote: > > Hi All > > > > I have a windows application that calls a > function ( > > approximately 10000 times) exported by a third party DLL. > > I have two machines ( one with Intel pentium 4 > > processor and > > other with Intel Xeon processor ) with RHEL 4.0 installed > on both > > of these > > machine. > > If I execute the windows application on the first > > machine (one > > with Intel pentium 4 processor ) using WINE, the execution > time is > > almost > > equal to the execution time in windows machine. > > But, if I execute the same application on the > second > > machine > > (Intel Xeon processor ), the execution time is almost 6 > times to > > the first > > machine. > > I am using WINE-0.9.2 and wine is installed by > > downloading the > > wine source code from winehq.org <http://winehq.org/> < > http://winehq.org/> > > Is it a known issue (or ) > > Do I need to do any additional configuration > setting to > > work with > > Intel Xeon processor ? > > > > Regards > > Ajay > > ------------------------------------------------------------------------ > > > > > > > > >

4 3

"Windows Everywhere" foresaw Wine back in 1993?
by Dan Kegel Feb. 11, 2006

Feb. 11, 2006

Back in 1993, OS/2 advocate Richard E. Hodges disagreed enough with a June 1993 Byte magazine article by John Udell "Windows, Windows Everywhere?" that he wrote a lengthy reply, and posted it widely; it was forwarded to comp.os.os2.misc, and said in part --- snip --- To lure Independent Software Vendors, "Windows Everywhere" offers a kind of "magic dust" that will end their cross-platform support problems. Microsoft claims that Windows programs will run on any computer with nothing but a simple recompile. Windows programs will run under Unix through an emulator. "Wings" will let you recompile into a native Macintosh application. --- snip --- Did Microsoft really talk up the idea of Unix being able to run Win32 apps via emulation on Unix, or was Hodges referring to things like Sun's WABI, which was announced in May '93? - Dan p.s. the original message can be seen in two parts, May 31st or June 2 1993 (usenet was slow back then!), "A Letter to Byte Magazine", http://groups.google.com/group/comp.os.os2.misc/msg/6180333e77f4a147 http://groups.google.com/group/comp.os.os2.misc/msg/e31a54eb9a3e1389 And the WABI announcement seems to be at http://groups.google.com/group/comp.unix.questions/msg/b4a8e8fc829b2ab7 -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 4

StretchDIBits function problem.
by Cyril Margorin Feb. 10, 2006

Feb. 10, 2006

Hello, I've discovered, that using of GetDIBits after StretchDIBits doesn't return correct data. More then - all pixels that it returns are black. In attachment the test function. Changelog: Cyril Margorin <comargo(a)gmail.com> add test of StretchDIBits()/GetDIBits() bunch to gdi/test/bitmap.c -- Cyril Margorin

4 4

Fact check for wine talk
by Dan Kegel Feb. 10, 2006

Feb. 10, 2006

Hi all, I'm giving a talk about Wine tomorrow. The slides are up at http://kegel.com/wine/scale4/ If you find any errors in the side, please let me know! Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

5 6

Re: localtime should accept any positive time value
by Marcelo Duarte Feb. 10, 2006

Feb. 10, 2006

Dmitry Timoshkov escreveu: > Hello, > Hello, > --- cvs/hq/wine/dlls/msvcrt/time.c 2006-01-23 20:50:58.000000000 -0600 > +++ wine/dlls/msvcrt/time.c 2006-02-10 12:51:30.000000000 -0600 > @@ -152,8 +152,12 @@ struct MSVCRT_tm* MSVCRT_localtime(const > SYSTEMTIME st; > DWORD tzid; > TIME_ZONE_INFORMATION tzinfo; > + ULONGLONG time; > > - ULONGLONG time = *secs * (ULONGLONG)TICKSPERSEC + TICKS_1601_TO_1970; > + /* time < 0 means a date before midnight of January 1, 1970 */ > + if (time < 0) return NULL; > + > + time = *secs * (ULONGLONG)TICKSPERSEC + TICKS_1601_TO_1970; > You compared the "time" before it has a assigned value... > > ft.dwHighDateTime = (UINT)(time >> 32); > ft.dwLowDateTime = (UINT)time; > @@ -161,7 +165,12 @@ struct MSVCRT_tm* MSVCRT_localtime(const > FileTimeToLocalFileTime(&ft, &lft); > FileTimeToSystemTime(&lft, &st); > > - if (st.wYear < 1970) return NULL; > + if (st.wYear < 1970) > + { > + /* if this happens it means that the sequence above does something wrong */ > + FIXME("seconds since 1970 %ld => %d/%d/%d %02d:%02d:%02d\n", *secs, > + st.wDay, st.wMonth, st.wYear, st.wHour, st.wMinute, st.wSecond); > + } > > data->time_buffer.tm_sec = st.wSecond; > data->time_buffer.tm_min = st.wMinute; > > ------------------------------------------------------------------------ > > >

1 0

Changes to Wine Status Pages
by Tom Wickline Feb. 10, 2006

Feb. 10, 2006

Hello, I plan to remove ttydrv from our dlls status page as it has been removed. And also remove Wine Installer (wineinstall) as it has been replaced by wineprefixcreate. Are there any comments on this before I remove these two components. Tom

2 1

Re: sfc: Add minimal sfc.dll
by Robert Shearman Feb. 10, 2006

Feb. 10, 2006

Detlef Riekenberg wrote: >+/***************************************************** >+ * DllMain >+ */ >+BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) >+{ >+ TRACE("(%p, %ld, %p)\n",hinstDLL, fdwReason, lpvReserved); >+ /* For the moment, do nothing here. */ >+ return TRUE; >+} > > You should call DisableThreadLibraryCalls here for performance reasons. -- Rob Shearman

1 0

Re: USER32: Hide cursor when calling SetCursor with NULL HCURSOR
by Andreas Mohr Feb. 10, 2006

Feb. 10, 2006

Hi, On Fri, Feb 03, 2006 at 07:50:51PM -0500, Justin Chevrier wrote: > Changelog: > Hide cursor if SetCursor is called with a NULL HCURSOR Which obviously implies the question: What if the program does a SetCursor(something) later? Should it then re-show a cursor previously hidden by a NULL handle? And if so, does Wine handle that re-showing properly? I'd better have a program with duplicate cursor than one without any cursor any more at all ;) Andreas

2 1

Re: Wine with multiple threads on Dual processor - any suggestions please
by Juan Lang Feb. 10, 2006

Feb. 10, 2006

Hi Ananth, > Is there any isses with wine on Dual processor machines ( Intel > Xeon processor ) w.r.t multi threaded programming? There can be, if there is a lot of inter-thread synchronization. Only if each thread is CPU-bound are you likely to see any improvement in performance as you move to multiple threads. If there is a lot of inter-thread synchronization, you'll be slowed down by calls into wineserver, and short of some hack this isn't going to change anytime soon. Regarding your other email, how do you know it's wine that's causing the difference in speed between the two machines? The machines are different. Different machines perform differently on different applications. Anyway, to investigate both of these problems, consider using oprofile. It was covered in wwn here: http://www.winehq.com/?issue=249#oprofile%20&%20Wine --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

MSACM: winemp3 codec crashes on seek, reimplement with libmad?
by Alex Villacís Lasso Feb. 9, 2006

Feb. 9, 2006

I was trying to exercise the winemp3 builtin codec using a Visual Basic control that essentially implements the Windows Media Player look (MSDXM.OCX). After specifying native quartz.dll for this app, I tested a few AVIs with mp3-encoded soundtracks. What I can notice is that the sound has very annoying jitters, and in addition, it crashes on a seek. Some people have noticed the jitters too (http://bugs.winehq.org/show_bug.cgi?id=3853) However, rather than trying to fix the wine fork of mpeglib, I was toying with the idea of reimplementing the codec as a libmad (GPL) wrapper. Are there any issues I should take into account before trying this? Alex Villacís Lasso

2 7