- Wine-devel - list.winehq.org

Problem with 64-bit file functions declarations
by Andriy Palamarchuk 31 May '02

31 May '02

I'm researching an issue when started regedit.exe fails to export registry. This started to happen after Alexandre's patch which included "config.h" in the regedit source file. I found out this problem was triggered by declaration #define _FILE_OFFSET_BITS 64 in config.h. The test case: ******************************************** /* Set this to 64 to enable 64-bit file support on Linux */ #define _FILE_OFFSET_BITS 64 #include <stdio.h> #include <windows.h> void test_write(void) { FILE *f = fopen("1.reg", "w"); printf("sizeof FILE: %d\n", sizeof(FILE)); fputs("DEBUG1\n", f); fclose(f); } int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { test_write(); exit(0); } ******************************************** Comment out the macro definition and it works, with macro it creates file of 0 length. With the defined macro many file functions are defined as functions for 64-bit access and are linked to the native platform calls instead of msvcrt ones. Differences in precompilation output: Without macro: # 203 "/usr/include/stdio.h" 3 extern FILE *fopen (__const char *__restrict __filename, __const char *__restrict __modes) ; With macro: # 211 "/usr/include/stdio.h" 3 extern FILE *fopen (__const char *__restrict __filename, __const char *__restrict __modes) __asm__ ("" "fopen64"); The same happens for some other file functions. What is the correct fix for this problem? Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

3 4

fwait bug
by admiral coeyman 31 May '02

31 May '02

Developers, From what I've been reading on the subject, the best way of handling int 3d is to return successful. Any fpu emmulation that we'll do should not require the fwait. The problem is that I cannot find enough information on the subject to know what the successful return conditions for this interrupt are. On a system that detects an FPU, self-modifying code is used. The interrupts that emmulate the FPU functions are rewritten in the executable to use the machine code for the real FPU instructions. I'm not sure if that can be done with the current memory scheme since that is outside of my area. God Bless, --Robert 'Admiral' Coeyman -- --- May you live as long as you wish and age but a single day. http://www.dotguy.net/ admiral(a)corner.net Webmaster/ Linux Administrator Computer Co-Op/CornerNet

1 0

Re: [Bug 377] Changed - mIRC crashes while backspacing to erase entry
by Tony Lambregts 31 May '02

31 May '02

Sam'l Bassett wrote: >With: > > codeweavers-wine-20011108-5 > >and > > mIRC 5.91 > > Yep -- still has the problem > >On Thursday 30 May 2002 12:35 pm, wine-bugs(a)winehq.com wrote: > > >>http://bugs.winehq.com/show_bug.cgi?id=377 >> >> >> Why do you not post in bugzilla the link was given . The reports come from the people looking at your bug report in bugzilla, where you reported it in the first place. Thats where you should respond. Tony Lambregts.

1 0

Re: PATCH: win32/device.c -- addresses two warnings
by Marcus Meissner 30 May '02

30 May '02

On Thu, May 30, 2002 at 09:26:56AM +0200, Gerald Pfeifer wrote: > This addresses two compiler warnings seen on FreeBSD 4.5-RELEASE. > The first should appear on any non GNU/Linux-system, the second on > all systems. > > Gerald > > ChangeLog: > Move floppy_params into #ifdef linux. > Fix printf format in OpenVxDHandle(). > > Index: device.c > =================================================================== > RCS file: /home/wine/wine/win32/device.c,v > retrieving revision 1.63 > diff -u -3 -p -r1.63 device.c > --- device.c 25 May 2002 22:04:43 -0000 1.63 > +++ device.c 30 May 2002 07:24:18 -0000 > @@ -1187,12 +1187,6 @@ static const DWORD VWIN32_DriveTypeInfo[ > 0x4f24 /* 2.88 M */ > }; > > -static BYTE floppy_params[2][13] = > -{ > - { 0xaf, 0x02, 0x25, 0x02, 0x12, 0x1b, 0xff, 0x6c, 0xf6, 0x0f, 0x08 }, > - { 0xaf, 0x02, 0x25, 0x02, 0x12, 0x1b, 0xff, 0x6c, 0xf6, 0x0f, 0x08 } > -}; > - > /********************************************************************** > * VWIN32_ReadFloppyParams > * > @@ -1201,6 +1195,12 @@ static BYTE floppy_params[2][13] = > static VOID VWIN32_ReadFloppyParams(DIOC_REGISTERS *regs) > { > #ifdef linux > + static BYTE floppy_params[2][13] = > + { > + { 0xaf, 0x02, 0x25, 0x02, 0x12, 0x1b, 0xff, 0x6c, 0xf6, 0x0f, 0x08 }, > + { 0xaf, 0x02, 0x25, 0x02, 0x12, 0x1b, 0xff, 0x6c, 0xf6, 0x0f, 0x08 } > + }; > + I think this is not recommended C (and might fail on other compilers). Not that linux would have any other but gcc. Ciao, Marcus

1 0

Re:Please how do I post the following and get help? "VT_STREAMED_OBJECT out of MSMQ"
by Hans 30 May '02

30 May '02

I was looking at some of your postings recently and I thought that maybe you have come across the situation where you have tried to send a VT_STREAMED_OBJECT into (OleSaveToStream) a queue body and tried to retrieve it at a later time (OleLoadFromStream). I am struggling to work with this (I hope that the code is self explanatory): pMsgProps->aPropID[iter] = PROPID_M_BODY_TYPE; pMsgProps->aPropVar[iter].vt = VT_UI4; pMsgProps->aPropVar[iter].ulVal = VT_STREAMED_OBJECT; iter++; pMsgProps->aPropID[iter] = PROPID_M_BODY; pMsgProps->aPropVar[iter].vt = VT_VECTOR|VT_UI1; STATSTG stat; hResult = ptrStream0->Stat(&stat,STATFLAG_NONAME); pMsgProps->aPropVar[iter].caub.cElems = stat.cbSize.LowPart; pMsgProps->aPropVar[iter].caub.pElems = (unsigned char *)static_cast<void *>(ptrStream0); The above part seems to go through fine. But I cannot extract the information from the receiving end: IStream* ptrStream0 = reinterpret_cast<IStream*>(pMsgProps->aPropVar[3].caub.pElems); // the subscript 3 is where the message body is being extracted, also memory has been allocated as UCHAR in the ..pElems hResult = ptrStream0->Stat(&stat,STATFLAG_NONAME); // the above line of code gives you garbage values for both STATMSG.cbSize.(HighPart and LowPart) Do you think that you could help? Thanks. Hans

1 0

Re: Patch to fix bug_report.pl
by Andreas Mohr 30 May '02

30 May '02

On Thu, May 30, 2002 at 09:47:07AM -0600, Tony Lambregts wrote: > The bug_report.pl script was broken by the removal of -managed command > line option This patch fixes it. That's all fine and dandy, but I think the real fix is to a) nuke bug_report.pl or b) improve it *a lot* bug_report.pl is so darn old that the Wine version it had originally been written for is *completely* different from what we're using today. Thus bug_report.pl should at least strip all "irrelevant" bug lines (*CriticalSection, Interlocked*crement, Tls*, ...). Furthermore it should really include many more debug lines (we're also tracing wine internal dlls now sometimes !). I'd suggest about 1500 lines of censored output, if not even more. Otherwise you can just kiss the debug log goodbye in about 98.5% of all cases. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

3 2

Debug information
by tijs＠connectux.com 30 May '02

30 May '02

Hi, I compiled a simple Hello World test using VC++ 6.0, with default settings. This generates a .PDB file, which is not read by the most recent winedbg. Perhaps this is due to an overly strict sanity check. In debugger/msc.c I found the following check if ( mpd_nth->Signature != IMAGE_NT_SIGNATURE || mpd_nth->FileHeader.NumberOfSections != nth->FileHeader.NumberOfSections || !(mpd_nth->FileHeader.Characteristics & IMAGE_FILE_DEBUG_STRIPPED )) goto leave; Now unfortunately, the characteristics for my file are 0x10e, and hence the IMAGE_FILE_DEBUG_STRIPPED flag is not set. Disabling the check solves this problem, but perhaps I should try to instruct VC++ to enable the bit? Trying the same with Visual Studio .NET is somewhat more cumbersome. I haven't been able to read in the debugging information generated by C++ projects using winedbg. Has anyone else tried this? Greetings, -- Tijs van Bakel, ConnecTUX, <tijs(a)connectux.com>

2 3

RE: Stripping of whitespaces at the end of lines
by Patrik Stridvall 30 May '02

30 May '02

> Alexandre Julliard a écrit : > > > > Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > > > > > If Alexandre wants to do it locally, I support him (our > mailboxes will > > > appreciate). > > > > If you want me to do that please send me a script that I can run > > across the tree to do the change. Please don't send patches for this > > kind of things. > > > > -- > > Alexandre Julliard > > julliard(a)winehq.com > > Here it is. It only targets .c and .h files. Looks good. <shameless-plug-for-perl> However the script can be written much shorter in Perl find . -name '*.[ch]' | xargs perl -i -pe 's/[ \t]+$//; s/;;+$/;/' </shameless-plug-for-perl> > The diff was ~4MB in size between before and after. The savings in a > .tar.gz of the whole tree were modest, around 25KB. I have read through the diff (rather quickly) and it seem to be OK. In fact I can't think of anything in the C semantics that can make a difference if trailing whitespace or extra semicolon is removed. > Now to find a good set of arguments to feed indent(1) so we > all use the > same coding style... > > Not! ;) Good luck finding something that everybody can agree upon. :-)

3 2

RE: Stripping of whitespaces at the end of lines
by Medland, Bill 30 May '02

30 May '02

> -----Original Message----- > From: Vincent Béron [mailto:vberon(a)mecano.gme.usherb.ca] > Sent: Tuesday, May 28, 2002 10:44 PM > To: wine-patches(a)winehq.org > Subject: Stripping of whitespaces at the end of lines > > > This is the first post in a series of posts about the same > subject. The > plan is to post the rest in the following days (as the total is >2MB > uncompressed, I don't want to send it all at once). Each patch will be > compressed (diff.gz) for that same reason. > > Alexandre, if you don't intend to apply it, please say so (along with > why), so I won't post some big patches for nothing. > > Changelog > - Strips whitespaces at the end of some C lines. > > Vincent I would have thought it would be safer simply for Alexandre to do the stripping locally rather than posting a whole load of patches. At the same time how about agreeing the size of a tab or removing them altogether or agreeing always to use tabs for progra, indentation or ....; Bill

11 19

Re: PATCH: ImageList_LoadImageW (comctl32)
by Tony Lambregts 30 May '02

30 May '02

Sander van Leeuwen wrote: >Changelog: >- Match behaviour of ImageList_LoadImageA wrt cx parameter (when set to zero) > >Author: Sander van Leeuwen/Odin (sandervl(a)xs4all.nl) > > >--- imagelist.c Wed May 29 17:31:28 2002 >+++ imagelist.co Wed May 29 17:32:38 2002 >@@ -1907,19 +1907,6 @@ > if (uType == IMAGE_BITMAP) { > BITMAP bmp; > GetObjectA (handle, sizeof(BITMAP), &bmp); >- >- /* To match windows behavior, if cx is set to zero and >- the flag DI_DEFAULTSIZE is specified, cx becomes the >- system metric value for icons. If the flag is not specified >- the function sets the size to the height of the bitmap */ >- if (cx == 0) >- { >- if (uFlags & DI_DEFAULTSIZE) >- cx = GetSystemMetrics (SM_CXICON); >- else >- cx = bmp.bmHeight; >- } >- > nImageCount = bmp.bmWidth / cx; > > himl = ImageList_Create (cx, bmp.bmHeight, ILC_MASK | ILC_COLOR, > > > > > > Seems to me that you got this patch backward. - should + Tony Lambregts

1 0