wine-devel April 2001

wine-devel@winehq.org

51 participants
93 discussions

Re: Trouble with VirtualQuery()
by Uwe Bonnes 25 Apr '01

25 Apr '01

>>>>> "Gerald" == <<gerard.patel(a)asi.fr>@s5.asi.fr> writes: Gerard > ... Gerard > Possibly I'll send a new patch if I find where is the flag Gerard > in the exe to handle the 3 gig memory space but as I am not Gerard > actively searching for it, you are welcome to do it yourself Gerard > :-) Do you mean http://support.microsoft.com/support/kb/articles/Q171/7/93.ASP ? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

New breakages
by gerard patel 25 Apr '01

25 Apr '01

Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x40a39b1b). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x40a39b1b (X11DRV_WND_SetGravity+0x1f [wnd.c:414]): cmpl $0,0x0(%edx) 414 if (data->window && data->bit_gravity != value ) Wine-dbg>bt bt Backtrace: =>0 0x40a39b1b (X11DRV_WND_SetGravity+0x1f(wnd=0x40367b80, value=0x1) [wnd.c:414]) (ebp=40c56b8c) 1 0x40a149dc (X11DRV_SetWindowPos+0x678(winpos=0x40c56c54) [winpos.c:1076]) (ebp=40c56c3c) 2 0x406acb69 (SetWindowPos+0x51(hwnd=0x1a20, hwndInsertAfter=0x0, x=0xdd, y=0xcf, cx=0x172, cy=0xef, flags=0x80000015) [winpos.c:2176]) (ebp=40c56c70) 3 0x40a3481e (EVENT_ConfigureNotify+0x1a6(hWnd=0x1a20, event=0x40c56d90) [event.c:983]) (ebp=40c56ccc) 4 0x40a33b0f (EVENT_ProcessEvent+0x49b(event=0x40c56d90) [event.c:438]) (ebp=40c56d70) 5 0x40a335ec (EVENT_ProcessAllEvents+0x68(arg=0x0) [event.c:209]) (ebp=40c56df0) 6 0x400c9b7f (SERVICE_Loop+0xbf(dummy=0x0) [services.c:76]) (ebp=40c56f1c) Hacked away by --- wnd.c.orig Wed Apr 25 01:43:41 2001 +++ wnd.c Wed Apr 25 09:28:52 2001 @@ -411,7 +411,7 @@ { X11DRV_WND_DATA *data = wnd->pDriverData; - if (data->window && data->bit_gravity != value ) + if (data && data->window && data->bit_gravity != value ) { XSetWindowAttributes win_attr; win_attr.bit_gravity = value; Another problem : now in the file open window, the tooltips for the toolbar buttons are appearing as managed windows (in managed mode of course) There may be other problems, I have not the time to search for them all just now. Gerard

1 0

Re: GDI syslevel held during psdrv init ... bad
by Alexandre Julliard 24 Apr '01

24 Apr '01

Marcus Meissner <marcus(a)jet.franken.de> writes: > Now the reason is, that pCreateDC is always called with the GDI syslevel (3) > held, so _any_ call to relaying here will dump. > > How do we fix this? We could probably get rid of the check. Syslevel locking is reasonably stable now, and dll separation will cause more and more false alarms here. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: fault handling - oof
by Alexandre Julliard 24 Apr '01

24 Apr '01

lawson_whitney(a)juno.com writes: > I got what looked like a recursive page fault somewhere in > startup/fixup_imports until I reverted all 3. A fixup_imports crash sounds a bit like what other people reported seeing with the shared sections fix. Did you run two instances of the application by any chance? -- Alexandre Julliard julliard(a)winehq.com

2 1

GDI syslevel held during psdrv init ... bad
by Marcus Meissner 24 Apr '01

24 Apr '01

Hi, While trying to debug something I come across this problem: Call gdi32.CreateICA(405b59eb "WINEPS",405b59d4 "Wine PostScript Driver",405b59f 2 "LPT1:",00000000) ret=007a6674 tid=08063338 trace:relay:PE_InitDLL CallTo32(entryproc=0x4bef3270,module=4beeb000,type=1,res= (nil)) err:psdrv:PSDRV_AFMGetCharMetrics missing ;, failed. [C 0 ; WX 600 ; N null] fixme:psdrv:PSDRV_FindPrinterInfo 'Wine PostScript Driver' Call kernel32.MultiByteToWideChar(00000000,00000000,4c057534 "Wine PostScript Dr iver",ffffffff,00000000,00000000) ret=40953fd4 tid=08063338 err:win32:SYSLEVEL_CheckNotLevel (2): Holding lock of level 3! Now the reason is, that pCreateDC is always called with the GDI syslevel (3) held, so _any_ call to relaying here will dump. How do we fix this? Ciao, Marcus

1 0

Re: problem with native dll's.
by Alexandre Julliard 23 Apr '01

23 Apr '01

Rein Klazes <rklazes(a)xs4all.nl> writes: > Since the cvs commits early this week or the last (I could be more > precise but that will take a while) I have noticed a problem with some > native dlls. > If I start one app that uses such a dll and then another using the > same dll may crash. If this second app is started as the first process > it runs fine. Most likely my shared sections fix: 2001-04-13 Alexandre Julliard <julliard(a)winehq.com> * server/file.c, server/mapping.c, server/object.h: Repaired shared PE data sections. The fix itself should be OK, but it probably reveals other bugs that were hidden by the fact that the sections were not shared properly before. For instance if a dll stores window handles in the shared area it will break since window handles are not shared yet (working on it...) In your case it doesn't seem to be window handles though, so it may be worth investigating a bit more. -- Alexandre Julliard julliard(a)winehq.com

4 3

Re: Virtual memory under Win95
by Alexandre Julliard 23 Apr '01

23 Apr '01

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > Perhaps applications which use assumptions about Win95 virtual memory > management should be considered as broken? Or it is worth to support them? What should be considered broken is the memory management of Win95 ;-) But yes, we should probably forget about making this kind of things work, we cannot possibly support the Win95 memory model 100% right anyway. Especially since the app works with -winver nt40, I think that's a reasonable work-around. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Msvcrt fixes
by Andreas Mohr 23 Apr '01

23 Apr '01

On Mon, Apr 23, 2001 at 12:27:58AM -0700, François Gouget wrote: > Btw, the Linux localtime documentation sucks. It's even worse than > the MS one!!! Err, fix it ? ;-) Really, what is an Open Source programmer supposed to do when he realizes that something sucks ? Food for thought, -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

3 3

Virtual memory under Win95
by Dmitry Timoshkov 23 Apr '01

23 Apr '01

Hello all. Could anybody with access to a Win95 machine run this simple program and report the result? void test(void) { HANDLE hMapping; void *p; MEMORY_BASIC_INFORMATION info; DWORD dwRet; hMapping = CreateFileMappingA(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE | SEC_RESERVE, 0, 0x0400f000, NULL); printf("hMapping = %04x\n", hMapping); p = MapViewOfFile(hMapping, FILE_MAP_READ ,0, 0, 0x00010000); printf("p = %p\n", p); UnmapViewOfFile(p); dwRet = VirtualQuery(p, &info, sizeof(info)); printf("VirtualQuery(%p) ret=0x%lx\n" "BaseAddress = %p\n" "AllocationBase = %p\n" "AllocationProtect = 0x%08lx\n" "RegionSize = 0x%08x\n" "State = %08lx\n" "Protect = %08lx\n" "Type = %08lx\n", p, dwRet, info.BaseAddress, info.AllocationBase, info.AllocationProtect, info.RegionSize, info.State, info.Protect, info.Type); } Thanks in advance.

4 6

Re: Virtual memory under Win95
by Alexandre Julliard 23 Apr '01

23 Apr '01

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > From http://msdn.microsoft.com/library/psdk/winbase/filemap_79wn.htm > > --- cut --- > "To fully close a file-mapping object, an application must unmap all mapped views > of the file-mapping object by calling UnmapViewOfFile, and close the file-mapping > object handle by calling CloseHandle. The order in which these functions are called > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > does not matter. The call to UnmapViewOfFile is necessary because mapped views of > ^^^^^^^^^^^^^^^ > a file-mapping object maintain internal open handles to the object, and a file-mapping > object will not close until all open handles to it are closed." > --- cut --- > > My patch is WRONG. MSDN says that until both CloseHandle and UnmapViewOfFile are called > the file-mapping object still exists. This is wrong for NT but true for Win9x. Why do you say it's wrong for NT? It seems perfectly correct: the mapping object exists as long as you have a handle to it, or some view of it is mapped (which keeps a handle internally, just like we do under Wine). Do not confuse the file mapping object with mapped views; the doc only talks about the mapping object. Specific views of the object are unmapped by UnmapViewOfFile (at least under NT), even if this may not cause the mapping object to be deleted. This doesn't contradict the doc at all. -- Alexandre Julliard julliard(a)winehq.com

3 2

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 April 2001