- Wine-Devel - list.winehq.org

Re: PATCH: libntddl.so not found
by Dustin Navea May 31, 2002

May 31, 2002

Hmmm, I found some problems with this: +print NEWMAKE <<EOF; shouldn't that be printf ? + \@if test -f /etc/ld.so.conf -a -z "`grep \$(libdir) /etc/ld.so.conf`" ; \\ shouldn't that be \$(LIBDIR) + echo " Add the line '\$(libdir)' to /etc/ld.so.conf" ; \\ I think that escaping the $ in this line is unnecessary as it this prints "$(libdir)" instead of the contents of that variable, and also libdir should be capitalized there too... + echo " export LD_LIBRARY_PATH=\$(libdir):\$LD_LIBRARY_PATH" ; \\ Same as above except that it doesn't apply to \$LD_LIBRARY_PATH as we want "$LD_LIBRARY_PATH" to be printed... -Dustin __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

2 2

Re: Idea for people with priveleges
by Dustin Navea May 31, 2002

May 31, 2002

--- Andriy Palamarchuk <apa3a(a)yahoo.com> wrote: > > --- Dustin Navea <speeddymon(a)yahoo.com> wrote: > > Well, AFAIK, there isn't reall a QA team, and if > > there > > is, they aren't checking out the bugs, because > > several > > bugs marked as resolved for over a year weren't > > closed > > until I went in and closed them.... > > Agree, we can simplify the things for now - skip > VERIFIED and RESOLVED steps in most cases - just > close > the bugs. > We can change the process later. > > Andriy > That is why I started this thread, we cant "just close the bugs" we have to resolve them first... We need 3 more options, probably would be easiest to implement in BugZilla 2.11: Close as Unresolved More information needed from User More testing Needed __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

1 0

Problem with 64-bit file functions declarations
by Andriy Palamarchuk May 31, 2002

May 31, 2002

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 May 31, 2002

May 31, 2002

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 May 31, 2002

May 31, 2002

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 May 30, 2002

May 30, 2002

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 May 30, 2002

May 30, 2002

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 May 30, 2002

May 30, 2002

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 May 30, 2002

May 30, 2002

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 May 30, 2002

May 30, 2002

> 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