wine-devel February 2003

wine-devel@winehq.org

141 participants
291 discussions

Re: CVS Update: reactos
by Steven Edwards 03 Feb '03

03 Feb '03

Hello All, Just wanted to let everyone know that we've hit our first major milestone with ReactOS. I dont have the changelog in front of me but to some it up here it the list that I know off the top of my head. Self-hosted builds now works CD-booting/Installing Simple Windowing (User32 Code adapted from WINE) More MS_VC applicaton/driver support Started implementing support for WINE dlls Better Networking support (TCP still broken) Once WINE hits 1.x we will again take a snapshot of your tree so we have standard debugging interfaces. Right now in or tree we dont use libwine but have our own dll that implements the debug channels. We also still need to adapt alot of the controls from WINE for our user32. Thanks for all the help Steven --- Jason Filby <jfilby(a)mok.lvcm.com> wrote: > CVSROOT: /CVS/ReactOS > Module name: reactos > Repository: reactos/include/reactos/ > Changes by: jfilby(a)mok.lvcm.com 03/02/01 07:34:35 > > Modified files: > reactos/include/reactos/: version.h > > Log message: > ReactOS 0.1.0 > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

2 2

32-->16 Calls: loader/ne/resource.c: krnl386.exe & kernel32: NE_DefResourceHandler: illegal call to AllocResource16
by Andrew Hughes 03 Feb '03

03 Feb '03

Looking at the remaining 32-->16 call: HGLOBAL16 WINAPI NE_DefResourceHandler( HGLOBAL16 hMemObj, HMODULE16 hModule, HRSRC16 hRsrc ) Given the above signature for this function, its abundant use of 16-bit calls (AllocResource16, GlobalLock16, GlobalRealloc16 - twice for the last two), and the fact that the NE stuff deals with Win16 executables, is this really a 32-bit function? Does it need conversion? -- Andrew :-) Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html "Windows is the one true OS. MS invented the GUI. MS invented the 32 bit OS. MS is open and standard. MS loves you. We have always been at war with Oceania."

2 1

Re: LISTVIEW_SetItemCount without LVS_OWNERDATA take 2
by Dan Kegel 03 Feb '03

03 Feb '03

Duane Clark wrote: > As Dimi pointed out, we should have infoPtr->nItemCount correct at the > end of every iteration through the loop. > > Changelog: > Implement LISTVIEW_SetItemCount without LVS_OWNERDATA Duane, you rock! That seems to fix a lot of display anomolies -- even the little 'minimize, maximize, close' widget shows up now! I'll have to play with it a bit more, but it could be that our app is now functional in Wine (modulo that pesky install bug that causes install to fail unless you do --debugmsg +ole > file 2>&1). Thanks! - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

Re: RPC marshalling patch
by Sylvain Petreolle 03 Feb '03

03 Feb '03

--- "Dimitrie O. Paun" <dpaun(a)rogers.com> a écrit : > On February 2, 2003 07:07 pm, Sylvain Petreolle wrote: > > The answer to 'how much' will be $50 USD if the question 'how' > gives a > > good answer :) > > Cool -- you're up on the page! :) > > > Why would it be difficult ? > > Cause it can cost a non-trivial amount. We'll have to work out a > way... > Maybe even mailing a $50USD bill in snail mail, eh? Whazt about a Paypal account ? ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1

Re: LISTVIEW_SetItemCount without LVS_OWNERDATA take 2
by Dimitrie O. Paun 02 Feb '03

02 Feb '03

On February 2, 2003 06:05 pm, Duane Clark wrote: > + infoPtr->nItemCount = 0; Are you sure that's right? What if we get called when the list is non-empty? What if we have 1000 items in the list, and we're called with nItems=50? Or we have 200 in the list already, and we're called with nItems=600? -- Dimi.

1 0

Re: LISTVIEW_SetItemCount without LVS_OWNERDATA
by Dimitrie O. Paun 02 Feb '03

02 Feb '03

On February 2, 2003 05:46 pm, Duane Clark wrote: > + infoPtr->nItemCount = nItems; We should have infoPtr->nItemCount correct at the end of every iteration through the loop, otherwise we get into problems if we run out of memory, and we exit the look early: > + if ( !(lpItem = (ITEM_INFO *)COMCTL32_Alloc(sizeof(ITEM_INFO))) ) > + return 0; -- Dimi.

1 0

infinite loop in msvcrt dll
by Michael Stefaniuc 02 Feb '03

02 Feb '03

Hello, when starting ACT!2000 with wine the program freezes after the main window is brought up and one wine process goes mad and eats all the cpu. Running strace on that pid dosn't show any system call and even the relay output stops. I've attached with gdb to the wine process and got a backtrace with 3569 entries. I've captured the output with screen and attached it. Seems to be a loop in an exception handler (sigsegv's over and over again). I hope that somebody can do more with the output. The last entries in the relay output are tons of: 00000009:Call kernel32.TlsGetValue(00000000) ret=405d833e 00000009:Ret kernel32.TlsGetValue() retval=402a7810 ret=405d833e 00000009:Call msvcrt.__CxxFrameHandler(403821f0,40592c60,4038226c,40382180) ret=400c42b7 fs=008f eax=179c3008 ebx=400f6204 ecx=4010de20 edx=40382d54 esi=403821f0 edi=400f5fe1 ebp=40382150 esp=40382124 ds=002b es=002b gs=0007 flags=00000246 00000009:Ret msvcrt.__CxxFrameHandler() retval=00000001 ret=400c42b7 fs=008f eax=00000001 ebx=400f6204 ecx=4010de20 edx=40382d54 esi=403821f0 edi=400f5fe1 ebp=40382150 esp=40382124 ds=002b es=002b gs=0007 flags=00000246 00000009:Call msvcrt.__CxxFrameHandler(403821f0,40592ce8,4038226c,40382180) ret=400c42b7 fs=008f eax=179c3030 ebx=400f6204 ecx=4010de20 edx=40382d54 esi=403821f0 edi=400f5fe1 ebp=40382150 esp=40382124 ds=002b es=002b gs=0007 flags=00000246 In the "-debugmsg +msvcrt" output i see some: warn:msvcrt:msvcrt_mbc_to_wc MultiByteToWideChar failed on 73 lines, but i suspect this is not the problem. When running with "-dll msvcrt=n" the error dosn't occur. Any tips how to debug this further? bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 3

Re: [D3D 91] Add vertex fog for transformed vertices
by Christian Costa 02 Feb '03

02 Feb '03

> > > > >Well, I think the easiest would be for you to send a cumulative patch over >mine as I think it's easier to track for Alexandre (and as I will do for >your Light 'merging' patch that I did not have time to comment before >committing due to vacations :-) ). > OK. > > > Lionel > >PS: I think it's better to comment on wine-patches submission on wine-devel > itself rather than here. > Christian

1 0

[Fwd: [D3D 91] Add vertex fog for transformed vertices]
by Christian Costa 02 Feb '03

02 Feb '03

1 0

Debugging crashes in 16 bit code?
by Dan Kegel 02 Feb '03

02 Feb '03

How does one tell what DLL contains a particular segment of 16 bit code in winedbg? For instance, there's a nice juicy exception that happens towards the end of the Resource Hunter installer, available as a free trial download at http://www.boilsoft.com/rchunter.html In wine = win2k mode, it happens early enough to break the install, but in wine's win98 mode, the install doesn't crash until quite late, and you can actually use the product. Here's a log of an installer run that crashed (with "Windows" = "win2k"): $ ~/wine/wine setup.exe fixme:seh:check_resource_write Broken app is writing to the resource data, enabling work-around fixme:ntdll:NtOpenThreadToken (0xfffffffe,0x00000008,0x00000000,0x40791ba4): stub fixme:ntdll:NtQueryInformationToken (0xcafe,2,(nil),0,0x40791b90): stub fixme:ntdll:NtQueryInformationToken (0xcafe,2,0x40791b7c,12,0x40791b90): stub fixme:ntdll:NtOpenThreadToken (0xfffffffe,0x00000008,0x00000000,0x4079154c): stub fixme:ntdll:NtQueryInformationToken (0xcafe,2,(nil),0,0x40791538): stub fixme:ntdll:NtQueryInformationToken (0xcafe,2,0x40791524,12,0x40791538): stub fixme:ntdll:NtOpenThreadToken (0xfffffffe,0x00000008,0x00000000,0x4079135c): stub fixme:ntdll:NtQueryInformationToken (0xcafe,2,(nil),0,0x40791348): stub fixme:ntdll:NtQueryInformationToken (0xcafe,2,0x40791334,12,0x40791348): stub fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet. wine: Unhandled exception, starting debugger... No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\CTL3D32.DLL' (0x41170000) ... Unhandled exception: privileged instruction in 16-bit code (0487:09b7). In 16-bit mode. 0x0487:0x09b7: ldsw 0x014a,%dx Wine-dbg> At that point, I know how to gather a few kinds of info helpful to people trying to track down the cause of the crash, namely 'bt', 'info regs' and 'disas' (giving the latter an address 0x20 or so lower than the crash address, to give a little context): Wine-dbg> info regs Register dump: CS:0487 SS:048f DS:048f ES:049f FS:0000 GS:0007 IP:09b7 SP:1768 BP:176e FLAGS:0246( - 00 I Z- -P1 ) AX:0000 BX:000b CX:0000 DX:0000 SI:01be DI:01be Wine-dbg> disas 0x0487:0x0977 0x0487:0x0977: movw $0x1be,%di 0x0487:0x097a: call 0x09d2 0x0487:0x097d: movw $0x1be,%si 0x0487:0x0980: movw $0x1be,%di 0x0487:0x0983: call 0x09e1 0x0487:0x0986: call 0x09a9 0x0487:0x0989: popw %ax 0x0487:0x098a: orb %ah,%ah 0x0487:0x098c: jnz 0x09a5 0x0487:0x098e: movw 0x4(%bp),%ax 0x0487:0x0991: movb $0x4c,%ah Wine-dbg> disas 0x0487:0x0993: testw $0x1,%cs:0x0794 0x0487:0x099a: jz 0x09a3 0x0487:0x099c: lcall 0x011f:0x0cdf 0x0487:0x09a1: jmp 0x09a5 0x0487:0x09a3: int $0x21 0x0487:0x09a5: popw %di 0x0487:0x09a6: popw %si 0x0487:0x09a7: popw %bp 0x0487:0x09a8: ret 0x0487:0x09a9: movw 0x01b4,%cx Wine-dbg> 0x0487:0x09ad: jcxz 0x09b6 0x0487:0x09af: movw $0x2,%bx 0x0487:0x09b2: lcall *0x1b2 -> 0x0000 0x0487:0x09b6: push %ds 0x0487:0x09b7: ldsw 0x014a,%dx 0x0487:0x09bb: movw $0x2500,%ax 0x0487:0x09be: testw $0x1,%cs:0x0794 0x0487:0x09c5: jz 0x09ce 0x0487:0x09c7: lcall 0x011f:0x0cdf 0x0487:0x09cc: jmp 0x09d0 That's fine and dandy, and maybe it'll help Marcus find the bug, but it leaves me scratching my head, wondering what DLL could be at fault, and how I could connect it to Wine source code or a vendor-supplied DLL. Which FM did I fail to R? I did have a look at http://www.winehq.org/docs/wine-devel/wine-debugger.shtml but it doesn't seem to even think winedbg can disassemble stuff by itself, so I wonder if that's not quite up to date. Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

2 2

Jump to page:

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 February 2003