wine-devel May 2003

wine-devel@winehq.org

123 participants
270 discussions

Re: Dependancies question ?
by Pouech Eric DMI AEI CAEN 13 May '03

13 May '03

> Surprisingly, after this "make depend && make" recompiles EveryThing in > my tree. > I dont understand why, almost no program relies on twain_32.dll.so, > so could someone shed some light here ? because it changed the include/config.h file, which contains all configuration specific information (libraries you have or you don't...). Since config.h is quite heavily included in Wine source, it implied the whole recompilation. HTH A+

1 0

Dependancies question ?
by Sylvain Petreolle 13 May '03

13 May '03

Hi, Today I removed my sane binaries (scanner program) since my CVS repository is too old. I made a "./configure" to disable the sane support in Wine. Surprisingly, after this "make depend && make" recompiles EveryThing in my tree. I dont understand why, almost no program relies on twain_32.dll.so, so could someone shed some light here ? ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1

DCE RPC documentation fund is collecting dust...
by Gregory M. Turner 13 May '03

13 May '03

My apologies for not announcing this sonner, but it seems that the DCE RPC documentation package, which many of you kindly donated funds for, is a no-go. I've spent some time researching what, if anything, we need from OpenGroup, and unfortunately, I've never been able to get a coherent answer, even from OpenGroup's sales people. Part of the problem seems to be that the DCE standard is "discontinued" by OpenGroup as a project. We wouldn't care if we knew what documents had relevance to wine. But it turns out that DCE covers a lot more than just RPC, most of which is not of interest to wine's RPC implementation. The RPC part of the standard, as far as I can tell, is freely available for download, including the fascinating "DCOM/ActiveX" standard (which refers to a separate ORPC standards document I have been unable to find, I'm afraid, to document the ORPC wire protocol :(; btw, I think Microsoft let their similar document fall of the 'net as well, you'll see links to it in various places... but I digress....) So, insofar as I have questions about whether or not there's anything useful in there, OpenGroup's sales lady is unable to help -- she don't even seem able to give me the information thats available on the website, much less elaborate on it. That leaves me with no choice but to guess what is useful based on the information available to me: which seems to indicate that we don't need anything we can't get for free from OpenGroup. So, the obvious question is, where does everyone's hard-earned money go? I've confirmed with Jeremy that refunds are an option; if you want your money back, let Jeremy know, and presumably he will make arrangements with you in private to get your money returned. For those of you who would rather have your donations go to some other wine-releated cause, the matter is open for discussion. One idea which has been tossed around in private discussions between myself, Jeremy and Dimi is to rededictae these funds to the Wine Party Fund or some other wine conference fund. Another would be to find some other documentation we need to buy and use it for that. But, it's your money, and since every contributor essentially has veto power over their own portion of the funds, we obviously want to build some kind of consensus. Sorry it took me so long to break this news, I spend a fair amount of time trying to salvage the original plan to buy the DCE doc's but it just didn't seem right to spend it on something which potentially has no value to wine... and then the guilt and procrastination set in... ;) Thanks for your patience on this matter. -- "Security is mostly superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. To keep our faces toward change and behave like free spirits in the presence of fate is strength undefeatable." --Helen Keller gmt

5 4

Re: toolbar - get rid of direct ImageList access hacks
by Vitaliy Margolen 13 May '03

13 May '03

Looks like resizing ToolBar buttons doesn't work this way. Needs more work. For a time being revert this change: Vitaliy Margolen changelog: - dlls/comctrl32/toolbar.c revert change for resizing buttons Index: dlls/comctl32/toolbar.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/toolbar.c,v retrieving revision 1.131 diff -u -r1.131 toolbar.c --- dlls/comctl32/toolbar.c 13 May 2003 03:36:54 -0000 1.131 +++ dlls/comctl32/toolbar.c 13 May 2003 06:03:24 -0000 @@ -29,7 +29,6 @@ * * * TODO: - * - A little bug in TOOLBAR_DrawMasked() * - Button wrapping (under construction). * - Messages. * - Notifications (under construction). @@ -67,6 +66,7 @@ #include "winuser.h" #include "wine/unicode.h" #include "commctrl.h" +#include "imagelist.h" #include "comctl32.h" #include "wine/debug.h" @@ -3952,8 +3952,12 @@ infoPtr->nBitmapWidth = (INT)LOWORD(lParam); infoPtr->nBitmapHeight = (INT)HIWORD(lParam); - if (himlDef) - ImageList_SetIconSize(himlDef, infoPtr->nBitmapWidth, infoPtr->nBitmapHeight); + + /* uses image list internals directly */ + if (himlDef) { + himlDef->cx = infoPtr->nBitmapWidth; + himlDef->cy = infoPtr->nBitmapHeight; + } return TRUE; }

1 0

Re: DOSVM_Int31Handler/DOSVM_CallRMInt crash
by Jukka Heinonen 13 May '03

13 May '03

Andreas Mohr wrote: > when running Win98 explorer.exe, I finally get this crash: ... > Backtrace: > 0 0x406cb9a3 (DOSVM_GetRMHandler+0x7(intnum=0x21) [interrupts.c:455] in winedos.dll.so) (ebp=41052560) > 1 0x406c7b8c (DOSVM_CallRMInt+0x28(context=0x4105290c) [int31.c:462] in winedos.dll.so) (ebp=41052850) > =>2 0x406c9b63 (DOSVM_Int31Handler+0x15f7(context=0x4105290c) [int31.c:1067] in winedos.dll.so) (ebp=410528dc) > 3 0x406cafc5 (DOSVM_IntProcRelay+0x9(context=0x4105290c, data=0x406c856c) [interrupts.c:121] in winedos.dll.so) (ebp=410528e8) > 4 0x406cd1ca (RELAY_RelayStub+0xe(proc=0x406cafbc, args=0x4038fcae, context=0x4105290c) [relay.c:116] in winedos.dll.so) (ebp=410528f8) > 5 0x400b57f0 (KERNEL32.DLL.__wine_call_from_16_regs+0x144 in libntdll.dll.so) ... > I assume it's because the DOS memory area hasn't been unprotected/set up > (grrr, this kind of problem *again*!) > > Where should this call sequence have activated the DOS memory area properly? Well, I was expecting this kind of problems, nice to finally have a test program. If we assume that we want to keep the lowest 64k protected for as long as possible, the first fix is to make DOSVM_GetRMHandler and DOSVM_SetRMHandler update interrupt vector in upper memory if DOS memory has not been unprotected. However, either DOSVM_CallRMInt or DOSVM_Int31Handler must unprotect memory because we are about to enter VM86. I have actually had some plans to keep the lowest 1 megabyte protected when process starts up and only unprotect and initialize DOS/BIOS stuff if it really is needed (and unprotect low 64k only after first access to it from VM86 mode). In this case we could push initialization code to winedos and we really would keep null pointer protection active for as long as possible. But, anyway, simple solution would be to add unprotect call to DOSVM_Int31Handler just before calling to DOSVM_CallRMInt. This would also fix DOSVM_GetRMHandler call in DOSVM_CallRMInt. Nice comment about why this is needed would also be fine. -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

Win32 Mozilla 1.4b+ GCC (MingW)?
by Brian Vincent (C) 13 May '03

13 May '03

Anyone see the release info for Mozilla 1.4 Beta? It says: "As of Mozilla 1.4b, it is possible to build Mozilla for Win32 using GCC." Here's the specific build instructions for Windows: http://www.mozilla.org/build/win32.html It notes: GCC for Win32 is available as part of the MinGW project. The following mingw packages are required for building: gcc >= 3.2.2 (20030208) binutils >= 2.13.90 (20030104) w32api >= 2.3 mingw-runtime >= 2.4 --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

4 6

DOSVM_Int31Handler/DOSVM_CallRMInt crash
by Andreas Mohr 12 May '03

12 May '03

Hi all, when running Win98 explorer.exe, I finally get this crash: First chance exception: page fault on read access to 0x00000084 in 32-bit code (0x406cb9a3). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:028f GS:0000 EIP:406cb9a3 ESP:41052560 EBP:41052560 EFLAGS:00010202( R- 00 I - - 1 ) EAX:00000021 EBX:406dc14c ECX:00000202 EDX:406dbfe6 ESI:4105290c EDI:00000e38 Stack dump: 0x41052560 (_end+0x22dc24): 41052850 406c7b8c 00000021 00000000 0x41052570 (_end+0x22dc34): 00000000 00000000 00000000 00000000 0x41052580 (_end+0x22dc44): 400d9280 40308000 0000000a 41052650 0x41052590 (_end+0x22dc54): 00000040 400d9280 41052650 40308000 0x410525a0 (_end+0x22dc64): 410525bc 400d9280 410525bc 00000016 0x410525b0 (_end+0x22dc74): 41052638 400931eb 410525bc 400d9280 0x410525c0 (_end+0x22dc84): 0051: sel=028f base=41063000 limit=00000fff 32-bit rw- Backtrace: 0 0x406cb9a3 (DOSVM_GetRMHandler+0x7(intnum=0x21) [interrupts.c:455] in winedos.dll.so) (ebp=41052560) 1 0x406c7b8c (DOSVM_CallRMInt+0x28(context=0x4105290c) [int31.c:462] in winedos.dll.so) (ebp=41052850) =>2 0x406c9b63 (DOSVM_Int31Handler+0x15f7(context=0x4105290c) [int31.c:1067] in winedos.dll.so) (ebp=410528dc) 3 0x406cafc5 (DOSVM_IntProcRelay+0x9(context=0x4105290c, data=0x406c856c) [interrupts.c:121] in winedos.dll.so) (ebp=410528e8) 4 0x406cd1ca (RELAY_RelayStub+0xe(proc=0x406cafbc, args=0x4038fcae, context=0x4105290c) [relay.c:116] in winedos.dll.so) (ebp=410528f8) 5 0x400b57f0 (KERNEL32.DLL.__wine_call_from_16_regs+0x144 in libntdll.dll.so) (ebp=41052c00) 6 0x086f:0x0146 (bp=450e) 7 0x0877:0x067d (bp=4522, far call assumed) 8 0x0877:0x07d7 (bp=4546) 9 0x07f7:0x07a9 (bp=45d6, far call assumed) 10 0x07f7:0x0a34 (bp=45e2) 11 0x07f7:0x0b54 (bp=4842) 12 0x07f7:0x0c56 (bp=485e) 13 0x07f7:0x0dbe (bp=487e) 14 0x07b7:0x0251 (bp=49ac, far call assumed) 15 0x07b7:0x0034 (bp=49b8) 16 0x073f:0x0458 (bp=49da, far call assumed) 17 0x073f:0x0411 (bp=49e4) 18 0x071f:0x0331 (bp=4b2a, far call assumed) 19 0x075f:0x0546 (bp=4cb0, far call assumed) 20 0x075f:0x007b (bp=4cc2) 21 0x079f:0x0130 (bp=4cd6, far call assumed) 22 0x0447:0x3e2c (bp=4e06, far call assumed) 23 0x02c7:0x6165 (bp=4e22, far call assumed) 24 0x029f:0x03a4 (bp=4e32, far call assumed) 0x406cb9a3 (DOSVM_GetRMHandler+0x7 [interrupts.c:455] in winedos.dll.so): movl 0x0(,%eax,4),%eax 456 } I assume it's because the DOS memory area hasn't been unprotected/set up (grrr, this kind of problem *again*!) Where should this call sequence have activated the DOS memory area properly? -- Help prevent Information Technology Fascism! - before it's too late... http://www.againsttcpa.com

1 0

Re: Create a new heap in start_debugger
by Eric Pouech 12 May '03

12 May '03

Robert Shearman wrote: > Create a new heap when the debugger is started in case the heap has been > corrupted. I don't think the fix is completly correct... in all cases, we need to keep the current heap... if the debugger continues the execution, then the old heap is needed (for example, HeapFree/HeapValidate will no longer work...) so, a proper fix (to deal with this situation) would be to: - set a new heap (as you did) - create the process for the debugger, but suspended - put back the old heap in the pdb - fire the debugger (ResumeThread) note anyway that the fix isn't perfect. for example, if an execption results from a corrupted heap, we may still use heap related functions in the exception handling code (the debugger startup is one of example, but is far from being the only one). For example, running with -debugmsg +seh is another one :-/ A+ -- Eric Pouech

2 1

Lotus Notes and wine and RedHat 9
by Joe Squire 12 May '03

12 May '03

Hi I apologize in advance for hitting the developers list. IANAD... I had been running wine on 7.2 with Lotus Notes 5.0.11 successfully. I made the unfortunate discovery about RH9 and threads and wine a little too late after upgrading to RH9. I will be more careful next time... Anyways, I downloaded the source (2003-05-08), and managed to configure with --with-nptl (as at http://www.winehq.org/index.php?issue=164#Wine%20&%20RedHat%209.0) make dep, make and make install it. (I am closer to a newbie than a developer, so this was a major achievement!). But I ran into a problem that has already been reported at (thank you google) http://www.winehq.com/hypermail/wine-devel/2003/05/0141.html (the issue was unresolved. Kevin rolled back to a previous wine source from 5/1/2003). As with that post, there had been no changes to the install in the wine directory. The Lotus Notes splash screen comes up. The background for Notes itself comes up. The password box appears, and the error happens when I punch in the password and hit OK. I noted the post by Uwe at http://www.winehq.com/hypermail/wine-devel/2003/05/0144.html , but Uwe was hinting at my newbiness with "Do you know how to integrate this in wine? If not, tell me to send you a patch for testing." The answer to both is No. Even if I received a patch, I wouldn't have a clue. I am willing to try, but would llikely need some hand holding...like which file, where it's located etc... Again, apologies for hassling the devel list, I'm out of my depth here, but I will help if I can. TIA ws PS: hope this helps someone else: - after initial install and attempting to run an app thru wine, it 'hung' at the end of the font 'registration' (not sure it that is the right term), ie once it had got to 100%. X was running at about 70% cpu and wine at 30%. Eventually I ctrl-c'd it and rebooted. - after trying again, i received an error about winedefault.reg. Googling for this didn't help me locate where it was. But it was in the most obvious place. The root of the source download. Ran regedit winedefault.reg - then ran into the above. PPS - words of encouragement. Notes is my last tie to Windows and wine is my saviour! _________________________________________________________________ MSN Instant Messenger now available on Australian mobile phones. Go to http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp

5 5

Re: PATCH: formatting fixes in files/smb.c
by Mike McCormack 12 May '03

12 May '03

Hi Gerald, Well, if you want somebody to blame, blame me. Personally, it doesn't bother me as much. If you think a few extra spaces cause headaches, try figuring out how to make a one line change in a ~500 line function with 30+ variables... if you want to clean stuff up, I think your time would be better spent splitting up some of the monster functions, rather than nitpicking spacing. Mike Gerald Pfeifer wrote: > I had submitted the following last summer, because the original code > really had made it more difficult for me to track down a bug: > > We certainly should not get anal rentative on this, but something like > int trn = 1234,i=0; > from files/smb.c where even a single line is inconsistent really > makes me wonder.

1 0

← Newer
1
...
15
16
17
18
19
20
21
...
27
Older →

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