wine-devel

wine-devel@winehq.org

84471 discussions

Wine console windows vs. [x]terminal
by Segin 13 Feb '06

13 Feb '06

Hi, I notice that Wine opens a Windows-like console window for console apps if they are started using the 'winedbg' loader. Is it possible to get all console apps to run like this without using winedbg? There is a Windows console program using pdcurses that I am trying to check for compatability, and having to startup winedbg to get the program to function is a bit much. It should also be noted that I do not read the wine-users mailing list at this time, but I do read wine-devel.

3 2

bugzilla account
by Michael Jung 12 Feb '06

12 Feb '06

Hi, I would like to change the status of bug 4322 to FIXED, but I'm not 'empowered' to do it. Whom do I have to talk to? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

3 2

Representation of virtual hardware in desktop managers [Was Bug 4551]
by Tom Spear (Dustin Booker, Dustin Navea) 12 Feb '06

12 Feb '06

Forwarded from Bugzilla bug 4551. Nowadays on Linux you do not see your virtual wine hardware drives in KDE or GNOME because they are not recognized. You have to open "invisible" folder "$HOME/.wine". Many users will not be able to do this. Maybe one could work out some standard with freedesktop.org so that users can easily access their virtual drive C:\ ? Who's work would that be? I am not sure about that, so sorry if this is not the right "inbox". I would liek to suggest to extend this standard to other virtual machines like Xen or Vmware. Thilo Pfennig

1 0

Re: Small CVS-Update-Script
by Christian Lachner 12 Feb '06

12 Feb '06

I know that there is something like my script out there but i did (again) spend some time on rewriting my own one since i like it better ;). This one is compeltely different from my first one - it works the same, but does some checks before doing anything , the code is written nicer and cleaner and the output is also very nice now :D. Have fun with this piece of code! On 10/2/05, Andreas Schneider <andreas.schneider(a)linux-gamers.net> wrote: > Hi gladiac, > > take a look at > > http://winecvs.linux-gamers.net/ > > Cheers, > > -- andreas > > Gladiac Spark wrote: > > This is nothing special but may be useful for some people out there > > having problems updating their cvs-trees or being lazy writing some > > commands in their console. Copy the 'getwinecvs' to /usr/src or wherever > > you want (don't forget to edit the SRC=Variable if you're doing so) and > > chmod it to give you x-rights. (e.g.: 'chmod 750 getwinecvs' without quotes) > > > > By running it, it will search for an existing wine-tree... if there is > > one, it will be cleaned and then updated; if not, the complete tree will > > be downloaded. > > When using -c as parameter for getwinecvs, it will automatically begin > > to compile after getting all the updates and then install. > > To see what it exactly does, have a look at the source. > > > > Even if it is called General CVS-Updater by gladiac it has been written > > FOR wine. I hope it is helpful for others. I know it's not very nerdy > > but.... who cares ;). > > > > > > ------------------------------------------------------------------------ > > > > > > -- > http://www.linux-gamers.net - your online gaming resource > >

3 9

Re: WINED3D: Fix a couple of FIXMEs
by Alexandre Julliard 12 Feb '06

12 Feb '06

"H. Verbeet" <hverbeet(a)gmail.com> writes: > The output of glGetString(GL_PROGRAM_ERROR_STRING_ARB) can get too > large for a normal FIXME. Use fprintf to stderr instead. You should use debugstr_a. fprintf will mess up the output. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Localize ShellFolder display names [1/3] advapi32: Implemented RegLoadMUIString[AW]
by Dmitry Timoshkov 11 Feb '06

11 Feb '06

On Sat, 2006-02-11 at 18:06 +0100, Michael Jung wrote: > ChangeLog: > Implemented RegLoadMUIString[AW] > -IMPORTS = kernel32 ntdll > +IMPORTS = user32 kernel32 ntdll I'd suggest to add user32 as a delayload import to not create circular dependency at load time. -- Dmitry.

1 0

[usp10] Add ScriptItemize, ScriptShape and ScriptPlace functionality
by Jeff L 11 Feb '06

11 Feb '06

Is there anything wrong with this patch? It does not seem to have been applied. Jeff L

4 3

Font Rendering
by Roland Kaser 11 Feb '06

11 Feb '06

Hello I noticed a strange behavior of the Font/Vector objects functionality of Corel Draw on diffrent SuSE 10 Systems. On one system Rotated Text works fine (without any failure) on a other system, rotated fonts became invisible on the screen. At pdf export, the fonts are normally visible. So it seems to be a graphics subsystem error. No winedebug output at all. Can somebody tell me which system libraries used for the font rendering functions? So that I can compare the two systems to find out where the font-rendering error cames from. Many thanks Roland Kaeser

1 0

Copy/Paste
by Roland Kaser 11 Feb '06

11 Feb '06

Hello I noticed a strange behavior of the copy/paste functionality of Corel Draw on diffrent SuSE 10 Systems. On one system copy/paste works fine (without any failure) on a other system there is no function at all. (itss storage error). Can somebody tell me which system libraries used for the copy/paste functions? So that I can compare the two systems to find out where the copy/paste error cames from. Many thanks Roland Kaeser

1 0

Re: localtime should accept any positive time value
by Rein Klazes 11 Feb '06

11 Feb '06

On Fri, 10 Feb 2006 22:10:29 -0600, you wrote: >- ULONGLONG time = *secs * (ULONGLONG)TICKSPERSEC + TICKS_1601_TO_1970; >+ /* time < 0 means a date before midnight of January 1, 1970 */ >+ if (*secs < 0) return NULL; I think the comment is incorrect: it should be *secs < 0; >- 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); >+ } If *secs < 3600, in time zones on the western hemisphere it is still 1969. Rein.

1 0

STROKEPATH and STROKEANDFILLPATH emf problem
by Terry_Higgins＠cimmetry.com 11 Feb '06

11 Feb '06

Since upgrading to Wine-20040914, we've noticed that a bug has been introduced in gdi32.dll that causes certain pen strokes to be drawn with thickness that is far too wide. The problem is in wine's handling of the STROKEPATH and the STROKEANDFILLPATH emf records when playing enhanced metafiles. Specifically, there seems to be a problem with an interaction between wine's temporary setting of a world transform and a pen selection that happens during processing of the record. In cvs on the Wine HQ site, we notice that a SelectObject() for the pen was inserted in function DC_UpdateXforms() in dlls/gdi/dc.c in revision 1.2 as follows: =================================================================== RCS file: /home/wine/wine/dlls/gdi/dc.c,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- wine/dlls/gdi/dc.c 2004/07/21 04:07:28 1.1 +++ wine/dlls/gdi/dc.c 2004/09/13 18:03:44 1.2 @@ -262,10 +262,13 @@ void DC_UpdateXforms( DC *dc ) dc->vport2WorldValid = DC_InvertXform( &dc->xformWorld2Vport, &dc->xformVport2World ); - /* Reselect the font back into the dc so that the font size + /* Reselect the font and pen back into the dc so that the size gets updated. */ if(memcmp(&oldworld2vport, &dc->xformWorld2Vport, sizeof(oldworld2vport))) + { SelectObject(dc->hSelf, GetCurrentObject(dc->hSelf, OBJ_FONT)); + SelectObject(dc->hSelf, GetCurrentObject(dc->hSelf, OBJ_PEN)); + } } The pen is set after the call that modifies the world transform to the identity and before it is reset back to its normal values. If we remove the call to SelectObject that selects the pen (shown in the code above), the bug disappears. Advice on the best way to proceed would be greatly appreciated. 1) Why was this change made? 2) Is the best fix simply to undo this change or is there a better solution (e.g. fix the strokepath implementation)?

2 3

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

11 Feb '06

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@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@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 11 Feb '06

11 Feb '06

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 10 Feb '06

10 Feb '06

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 10 Feb '06

10 Feb '06

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 10 Feb '06

10 Feb '06

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 10 Feb '06

10 Feb '06

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 10 Feb '06

10 Feb '06

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 10 Feb '06

10 Feb '06

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 10 Feb '06

10 Feb '06

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 09 Feb '06

09 Feb '06

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

error: length() does not define an explicit binding handle!
by Uwe Bonnes 09 Feb '06

09 Feb '06

Hello, a recent CVS checkout gives ../tools/widl/widl -I. -I. -I../include -I../include -h \ -H mshtml.h mshtml.idl error: length() does not define an explicit binding handle! make[1]: *** [mshtml.h] Fehler 2 Any hints? -- 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

Regression problems in app - help with debugging?
by Dr J A Gow 09 Feb '06

09 Feb '06

Hello All, I have some regression problems relating to Wine in a commercial ECAD app 'Easy-PC' version 9.0, available from http://www.numberone.com The application was quite usable on Crossover Office 4.2, with just some minor dialog corruption. Alpha versions of Wine available at the same time (can not exactly remember which ones) could also run it successfully. However, under the latest Wine 0.9.6, Wine CVS and CXO 5.0.1 it does not work. Note that it does not crash, it errors out cleanly with a dialog box message. I have been debugging the problems in this app for some time now. It is a critical app for me as I use it in a production environment, but I do not want to pay Microsoft for the privilege of exposing my machine to malware. I am thus prepared to help debug Wine to get this application running. However, my Windows programming experience is limited to device drivers, not apps (although fluent C/C++ systems programming on other platforms), I have hit a brick wall, possibly due to my limited knowledge of how the Windows API works and I will need some help with this. If anyone would like to help me debug this app (hope springs eternal!), a demo version of the app is available free of charge from the web site address above, and this version exhibits the same problems as the full version. Background ------------- The system: Dual physical processor (not dual core) Opteron running SuSE 10.0 x86_64 SMP. Wine: Latest 0.9.6 release, up to CVS grabbed a week or so ago. The application installs OK and when run, puts up a GUI as expected. However, when you try to create a new PCB or schematic, an error dialog box is displayed indicating that the app can not read the technology file Default.stf (schematic) or Default.ptf (pcb). This is _not_ a permissions problem, all files are actually present and the same install will work under CXO 4.2. I generated and analyzed several hundred MB of logfiles over many days, added extra debug statements to the Wine code and analyzed the application's operation. The problem actually appears to have two causes, and this is what I have come up with so far. Problem 1 ----------- Application calls StgOpenStorage with a grfMode flag of 0x10020 (STGM_TRANSACTED | STGM_SHARE_DENY_WRITE). Immediately afterwards it calls StorageBaseImpl_OpenStream with a grfMode of 0x12 (STGM_SHARE_EXCLUSIVE | STGM_READWRITE). This second call fails with an access denied error code, after which the logs show an easily traced error handling sequence leading to display of the error dialog mentioned above: 0009:Call ole32.StgOpenStorage(59693db0 L"c:\\Program Files\\Number One Systems\\Easy-PC\\Technology\\Default.ptf",00000000,00010020,00000000,00000000,5821f850) ret=1022e7f0 ... ... trace:storage:StgOpenStorage <-- 00000000, IStorage 0x5b3465f8 0009:Ret ole32.StgOpenStorage() retval=00000000 ret=1022e7f0 ... ... trace:storage:StorageBaseImpl_OpenStream (0x5b3465f8, L"\0005FileType", (nil), 12, 0, 0x5821f848) fixme:storage:StorageBaseImpl_OpenStream STORAGE ACCESS DENIED - parent 0, this 2 Note that the last fixme is one I added to find out exactly what was going on here. Now, logic would dictate that the grfMode of the OpenStream method call is indeed incompatible with that of its parent storage object. However, I would have thought that the application coders would most likely have hard-coded the grfMode flags in the application. If so, it would seem that the app is buggy, yet this application works on Windows! Either the app is buggy and the Win32 OLE32 implementation behaves differently, or I am missing something here. Ok, so with no obvious solution to this problem, I decided to bypass it. I modified the storage32.c implementation in the following way to bypass the grfMode check: parent_grfMode = STGM_ACCESS_MODE( This->ancestorStorage->base.openFlags ); *if* ( STGM_ACCESS_MODE( grfMode ) > STGM_ACCESS_MODE( parent_grfMode ) ) { FIXME("StorageBase_OpenStream called with grfMode mismatch - parent %d, this %d\n", parent_grfMode,STGM_ACCESS_MODE(grfMode)); ///res = STG_E_ACCESSDENIED;/ ///goto end;/ } Obviously not a viable fix, but a hack to get it working. After implementing this, the OpenStream call succeeded, as did subsequent stream access. However, the app _still_ errored out in exactly the same manner and at the same time. After more log searching, this led to the discovery of the second problem. Problem 2 ----------- During its loading and setup, the application repeatedly calls StgOpenStorage on the .stf/.ptf files in question, calls OpenStream, reads from the stream, and then finally closes the storage. I placed tell-tales in useful locations in the file open/close handlers in the wineserver, and could clearly see the files being opened and subsequently closed. This open/read/close occurs correctly and in sequence up to a certain point. At this point in the execution, the app calls StgOpenStorage on the technology file, with the following call. It is opened correctly, with grfMode of STGM_TRANSACTED | STGM_SHARED_DENY_WRITE | STGM_READWRITE: 0009:Call ole32.StgOpenStorage(5821f754 L"c:\\Program Files\\Number One Systems\\Easy-PC\\Technology\\Default.ptf",00000000,00010022,00000000,00000000,5821f7f4) ret=7c17eabc trace:storage:StgOpenStorage (L"c:\\Program Files\\Number One Systems\\Easy-PC\\Technology\\Default.ptf", (nil), 10022, (nil), 0, 0x5821f7f4) ... ... ... trace:storage:StorageBaseImpl_AddRef (0x5b3465f8) AddRef to 1 trace:storage:StgOpenStorage <-- 00000000, IStorage 0x5b3465f8 0009:Ret ole32.StgOpenStorage() retval=00000000 ret=7c17eabc Almost immediately, the app opens three streams in this object and starts to access them, all successfully. There follows a whole slew of logging statements, all of which appear sensible However, what is strange about this access is that soon we seem to be frantically increasing the storage object's reference pointer. This sequence appears frequently in the code, closely spaced but interspersed with what seems quite logical and successful calls to seek functions and memory allocation functions: 0009:Call ntdll.RtlAllocateHeap(55890000,00000000,00000030) ret=584e498b 0009:Ret ntdll.RtlAllocateHeap() retval=55926480 ret=584e498b trace:storage:StorageBaseImpl_AddRef (0x5b3465f8) AddRef to 9 trace:storage:StorageImpl_ReadProperty storage name: L"\0005SummaryInformation" 0009:Call ntdll.RtlAllocateHeap(55890000,00000000,00000008) ret=584e7ab3 0009:Ret ntdll.RtlAllocateHeap() retval=5594d108 ret=584e7ab3 The storage object's reference pointer is so incremented up to 19: 0009:Call ntdll.RtlAllocateHeap(55890000,00000000,00000030) ret=584e498b 0009:Ret ntdll.RtlAllocateHeap() retval=559250f8 ret=584e498b trace:storage:StorageBaseImpl_AddRef (0x5b3465f8) AddRef to 19 trace:storage:StorageImpl_ReadProperty storage name: L"\0005SummaryInformation" 0009:Call ntdll.RtlAllocateHeap(55890000,00000000,00000008) ret=584e7ab3 0009:Ret ntdll.RtlAllocateHeap() retval=55925130 ret=584e7ab3 Finally, the code executes a trace:storage:StgStreamImpl_Destroy (0x5b34b7e0) trace:storage:StorageBaseImpl_Release (0x5b3465f8) ReleaseRef to 18 There follows a lot more log file, mostly concerned with set up and so on. What I am highligting here is that between this point, and the point of actual failure which I am going to describe shortly, there appears to be no attempt to close the Default.ptf file, unlike the attempts further up the logs closer to program start. I am wondering about this: is the reference counter being incorrectly incremented here, preventing the 'Release' function from destroying the storage object and thus closing the file? I am not sufficiently familiar with the COM storage object stuff in Windows to know what _should_ happen here. Anyway. I will now describe the point of failure. Further down the log, there are several more successful opens/closes of the technology file, with the correct mode flags. Then, finally, the app tries to re-open the technology file with a grfMode of STGM_TRANSACTED | STGM_SHARE_DENY_WRITE. This call fails with a sharing violation (remember it had been left open from the previous call) 0009:Call ole32.StgOpenStorage(5971bec8 L"c:\\Program Files\\Number One Systems\\Easy-PC\\Technology\\Default.stf",00000000,00010020,00000000,00000000,5821e69c) ret=1022e7f0 .... .... 0009:Ret kernel32.CreateFileW() retval=ffffffff ret=584edc8b trace:storage:StgOpenStorage <-- 80030020, IStorage (nil) There then follows the same error handling sequence leading to display of the dialog. I then thought about a simple test. I overrode the sharing mode detection in fd.c/check_sharing() in the wineserver (again, not a real solution). Note there are some minor differences in the code - I used a return code so I could easily check it: /// if ((access & FILE_UNIX_READ_ACCESS) && !(existing_sharing & FILE_SHARE_READ))/ /// rc=0;/ /// if ((access & FILE_UNIX_WRITE_ACCESS) && !(existing_sharing & FILE_SHARE_WRITE))/ /// rc=0;/ /// if ((existing_access & FILE_UNIX_READ_ACCESS) && !(sharing & FILE_SHARE_READ)) rc=0;/ /// if ((existing_access & FILE_UNIX_WRITE_ACCESS) && !(sharing & FILE_SHARE_WRITE)) rc=0;/ *if* (fd->closed->unlink[0] && !(existing_sharing & FILE_SHARE_DELETE)) rc=0; *if* (unlink && !(sharing & FILE_SHARE_DELETE)) rc=0; *if*(rc==0) { fprintf(stderr,"FILEDESC - sharing mode invalid\n"); rc=1; } *return* rc; and the application worked! Not only worked, but worked perfectly! The minor dialog corruption of previous versions had completely gone! I would like to thank the hard working people who have been working to correct problems in Wine, and in doing so had fixed this minor dialog problem. The only issue of note then is that the top-right hand buttons of a maximized MDI child window do not appear until you resize the frame. This is a minor issue though, and not of importance here. However, what I did does not represent a real solution - I just hacked around the problem, which itself seems subtle in nature. I looked closely at the Microsoft documentation and the logic in check_sharing(), even writing a program in Windows to check that at the CreateFile level that the sharing logic in Wine is correct. It seems to be. I am now stumped, I would really like to get this app working properly under Wine, without bad hacks. I would appreciate any guidance from those more experienced with the user-land Windows API. If you got this far, many thanks for taking the time to read this long message. I have provided only small excerpts from logs, but I can provide other parts of the files on request if necessary. John.

2 3

Problems compiling latest git version
by Paul Vriens 09 Feb '06

09 Feb '06

Hi, with the latest git version (is that the correct naming?) I'm getting: make[1]: Entering directory `/wine/wine-git/include' ../tools/widl/widl -I. -I. -I../include -I../include -h -H mshtml.h mshtml.idl error: length() does not define an explicit binding handle! make[1]: *** [mshtml.h] Error 2 make[1]: Leaving directory `/wine/wine-git/include' make: *** [include] Error 2 any ideas? Paul.

3 2

wine on Intel Xeon processor
by Ananth M 09 Feb '06

09 Feb '06

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 Is it a known issue (or ) Do I need to do any additional configuration setting to work with Intel Xeon processor ? Regards Ajay

1 0

Jump to page:

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