April 2001 - Wine-Devel - list.winehq.org

Re: Virtual memory under Win95

by Dmitry Timoshkov

"Ulrich Weigand" <weigand(a)immd1.informatik.uni-erlangen.de> wrote: > VirtualQuery in Win95, however, appears to completely ignore the > KERNEL32 list of views, but always calls the _PageQuery VMM service > and returns VMM's opinion on the status of the pages. This explains > why VirtualQuery shows the pages still present after UnmapViewOfFile. Perhaps applications which use assumptions about Win95 virtual memory management should be considered as broken? Or it is worth to support them? In my case installer works very well with -winver nt40 switch, but certainly there are other applications written for Win9x in mind only...

April 23, 2001

Re: DDraw,DGA bug?

by Ove Kaaven

On Sat, 21 Apr 2001 wine(a)henkis.net wrote: > I seem to have a problem running Direct Draw under wine, when changing screens > is a game i get to keep the old screen and the new screen is being drawed under > the old screen. (Seen it by manualy changing resolution). If you can manually change resolution (and window layers matter, i.e. the concept of "under" exists at all), you're not using DGA. Which game, anyway?

April 22, 2001

Re: Virtual memory under Win95

by Ulrich Weigand

Alexandre Julliard wrote: > 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. I think the cause for the behaviour observed by Dmitry might be the strange implementation of mapped views in Win9x: as I recall, there's on the one hand a list of mapped views per process maintained by KERNEL32, but on the other hand the actual address space management is done by VMM, which has *also* something like a list of mapped regions per address space. UnmapViewOfFile in Win95 does remove the view from the KERNEL32 list of views per process. However, it then only calls the _PageFlush VMM service on the address range, which does not actually remove the pages from VMM's lists, but only flushes all dirty pages to their backing store ... VirtualQuery in Win95, however, appears to completely ignore the KERNEL32 list of views, but always calls the _PageQuery VMM service and returns VMM's opinion on the status of the pages. This explains why VirtualQuery shows the pages still present after UnmapViewOfFile. Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

April 22, 2001

Re: Virtual memory under Win95

by Alexandre Julliard

"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

April 22, 2001

Re: InstallShield and ole question...

by Daniel Walker

Marcus Meissner wrote: > > On Wed, Apr 18, 2001 at 10:42:24AM -0400, Mike Bond wrote: > > > > My question, is anyone currently working on implementing CLSCTX_LOCAL_SERVER > > in compobj.c:CoGetClassObject, or have plans to work on this in the near > > future? If not, I may go back to trying to figure out what is happening > > with the 'native' configuration. > > This will require a lot of work, basically you will need to implement > all of the OLE out of process, marshalling, rpc stuff. > > This is not a trivial 100 line patch, its more like 20000+ lines. The CLSCTX_LOCAL_SERVER is used for function calls in another process on the same machine. So you wouldn't need any rpc, and I wouldn't think you would need marshalling .. In the case of InstallShield v6 it isn't really requesting anything from another process. It's requesting an object from an EXE, instead of a DLL. Daniel Walker

April 22, 2001

Trouble with VirtualQuery()

by Daniel Walker

I've been investigating the free Borland ilink32.exe , the one that locks under wine. Has this been discussed already? Well anyway, it probes several memory address with VirtualQuery(). This first location is 0x80000000 . On a normal windows system that would be system memory. Wine claims that area as free memory. Well apparently ilink32 doesn't want to see that region as free memory so it goes into an endless loop . There is a big list of memory location that it checks and if it doesn't get an acceptable result (Reserved) then it goes into an endless loop. If I set all the address to, info->State = MEM_RESERVED; info->Protect = PAGE_NOACCESS; info->AllocationProtect = PAGE_NOACCESS; info->Type = MEM_PRIVATE; Then ilink32 doesn't lock, but it has four internal memory errors. It still doesn't work, but it exit with an error. Here is the first set of addressed, 0x80000000 0x80FFF000 0x81FFE000 0x82FFD000 0x83FFC000 0xADC00000 0xAEBFF000 0xBFB70000 0xA0000000 0x83FFE000 0x81FFF000 0xA1FFF000 0x90000000 0x91FFF000 0xB1BFE000 0x91FFF000 0x98000000 0x99FFF000 0xB8000000 0xBA000000 Daniel Walker

April 22, 2001

Re: Virtual memory under Win95

by Dmitry Timoshkov

continue talking to myself... Anybody here? :-) > Comment about SEC_RESERVE in memory/virtual.c tells enough, besides the fact that Win95 > does not unmap regions allocated with that flag set. >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. Could anybody add CloseHandle and yet another VirtualQuery calls at the end of my test and run it under Win9x?

April 22, 2001

Re: Virtual memory under Win95

by Dmitry Timoshkov

I wtote: > "Rein Klazes" <rklazes(a)xs4all.nl> wrote: > > > win95 on a vmware machine. > > > > H:\>test > > hMapping = 0005 > > p = 826DB000 > > VirtualQuery(826DB000) ret=0x1c > > BaseAddress = 826DB000 > > AllocationBase = 826DB000 > > AllocationProtect = 0x00000001 > > RegionSize = 0x0400f000 > > State = 00002000 > > Protect = 00000001 > > Type = 00020000 > > This means that Win95/98 doesn't free region allocated with SEC_RESERVE flag set. > Could you please test other SEC_ flags? Is the result the same? Comment about SEC_RESERVE in memory/virtual.c tells enough, besides the fact that Win95 does not unmap regions allocated with that flag set. Attached patch makes the debugged installer proceed much further with -winver win95 switch now. Unfortunately currently there is no way to distinguish regions allocated with SEC_RESERVE flag set. Now installer DebugBreak's after another VirtualQuery call. Could you (or anybody else with a Win95 machine) add the following lines at the end of the previous test program and report the result? dwRet = VirtualQuery(p + 0x10000, &info, sizeof(info)); printf("VirtualQuery(%p) ret=0x%lx\n" "BaseAddress = %p\n" "AllocationBase = %p\n" "AllocationProtect = 0x%08lx\n" "RegionSize = 0x%08lx\n" "State = %08lx\n" "Protect = %08lx\n" "Type = %08lx\n", p + 0x10000, dwRet, info.BaseAddress, info.AllocationBase, info.AllocationProtect, info.RegionSize, info.State, info.Protect, info.Type); As usually thanks in advance (to Uwe Bonnes too! He sent his result privately).

April 22, 2001

problems while using yahoo! messenger

by K.Shyam

hello; i am getting the following error message while running yahoo messenger using linux. can someone help me.i am new to wine as such and it might take some time for me to understand how it exactly works... thank you K.Shyam fixme:win32:DeviceIo_MMDEVLDR (5,(nil),0,0x40394dbc,4,0x405a6ab8,(nil)): stub fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device NWLINK fixme:debug:FlushInstructionCache (0xffffffff,0x42aa1ee8,0x0000000d): stub fixme:debug:FlushInstructionCache (0xffffffff,0x42aa1e00,0x0000000d): stub fixme:debug:FlushInstructionCache (0xffffffff,0x42aa1d10,0x0000000d): stub fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:debug:FlushInstructionCache (0xffffffff,0x42aa1b18,0x0000000d): stub err:shell:IShellFolder_fnBindToObject can't bind to a file this is my config file : WINE REGISTRY Version 2 ;; All keys relative to \\Machine\\Software\\Wine\\Wine\\Config ;; ;; MS-DOS drives configuration ;; ;; Each section has the following format: ;; [Drive X] ;; Path=xxx (Unix path for drive root) ;; Type=xxx (supported types are 'floppy', 'hd', 'cdrom' and 'network') ;; Label=xxx (drive label, at most 11 characters) ;; Serial=xxx (serial number, 8 characters hexadecimal number) ;; Filesystem=xxx (supported types are 'msdos'/'dos'/'fat', 'win95'/'vfat', 'unix') ;; This is the FS Wine is supposed to emulate on a certain ;; directory structure. ;; Recommended: ;; - "win95" for ext2fs, VFAT and FAT32 ;; - "msdos" for FAT16 (ugly, upgrading to VFAT driver strongly recommended) ;; DON'T use "unix" unless you intend to port programs using Winelib ! ;; Device=/dev/xx (only if you want to allow raw device access) ;; [Drive A] "Path" = "/mnt/floppy" "Type" = "floppy" "Label" = "Floppy 0" "Device" = "/dev/fd0" [Drive C] "Path" = "/win" "Type" = "hd" "Label" = "MS-DOS 0" "Filesystem" = "win95" [Drive D] "Path" = "/mnt/cdrom" "Type" = "cdrom" "Label" = "CD-ROM 0" "Filesystem" = "win95" "Device" = "/dev/cdrom" [Drive E] "Path" = "/tmp" "Type" = "hd" "Label" = "Tmp Drive" "Filesystem" = "win95" [Drive F] "Path" = "/" "Type" = "network" "Label" = "Root" "Filesystem" = "win95" [Drive G] "Path" = "${HOME}" "Type" = "network" "Label" = "Home" "Filesystem" = "win95" [wine] "Windows" = "C:\\windows" "System" = "C:\\windows\\system" "Path" = "C:\\windows;C:\\windows\\system;E:\\;G:\\" "Profile" = "C:\\windows" "Temp" = "E:\\" "GraphicsDriver" = "x11drv" "ShellLinker" = "wineshelllink" # <wineconf> [DllDefaults] "EXTRA_LD_LIBRARY_PATH" = "${HOME}/wine/cvs/lib" "DefaultLoadOrder" = "native, builtin, elfdll, so" [DllOverrides] "kernel32" = "builtin" "gdi32" = "builtin" "user32" = "builtin" "krnl386" = "builtin" "kernel" = "builtin" "gdi" = "builtin" "user" = "builtin" "toolhelp" = "builtin" "comdlg32" = "elfdll, builtin, native" "commdlg" = "elfdll, builtin, native" "version" = "elfdll, builtin, native" "ver" = "elfdll, builtin, native" "shell32" = "builtin, native" "shell" = "builtin, native" "lz32" = "builtin, native" "lzexpand" = "builtin, native" "commctrl" = "builtin, native" "comctl32" = "builtin, native" "wsock32" = "builtin" "winsock" = "builtin" "advapi32" = "builtin, native" "crtdll" = "builtin, native" "ntdll" = "builtin, native" "mpr" = "builtin, native" "winspool" = "builtin, native" "winspool.drv" = "builtin, native" "ddraw" = "builtin, native" "dinput" = "builtin, native" "dsound" = "builtin, native" "winmm" = "builtin" "w32skrnl" = "builtin" "msvfw32" = "builtin" "mmsystem" = "builtin" "msvideo" = "builtin, native" "msvfw32" = "builtin, native" "mcicda.drv" = "builtin, native" "mciseq.drv" = "builtin, native" "mciwave.drv" = "builtin, native" "mciavi.drv" = "native, builtin" "mcianim.drv" = "native, builtin" "msacm.drv" = "builtin, native" "midimap.drv" = "builtin, native" "w32skrnl" = "builtin" "wnaspi32" = "builtin" "wow32" = "builtin" "system" = "builtin" "display" = "builtin" "wprocs" = "builtin" "wineps" = "builtin" "icmp" = "builtin" [x11drv] ; Number of colors to allocate from the system palette "AllocSystemColors" = "100" ; Use a private color map "PrivateColorMap" = "N" ; Favor correctness over speed in some graphics operations "PerfectGraphics" = "N" ; Color depth to use on multi-depth screens ;;ScreenDepth = 16 ; Name of X11 display to use ;;Display = :0.0 ; Allow the window manager to manage created windows "Managed" = "Y" ; Run Wine windows in desktop. Contains "N" or something like "800x600". ; Note Wine currently supports this option only on command line. ; So this option has currently no effect. Hope this will change. "Desktop" = "N" ; Use XFree86 DGA extension if present "UseDGA" = "Y" ; Use XShm extension if present "UseXShm" = "Y" ; Enable DirectX mouse grab "DXGrab" = "N" ; Create the desktop window with a double-buffered visual ; (useful to play OpenGL games) "DesktopDoubleBuffered" = "N" ; Code page used for captions in managed mode ; 0 means default ANSI code page (CP_ACP == 0) "TextCP" = "0" [fonts] ;Read documentation/fonts before adding aliases "Resolution" = "96" "Default" = "-adobe-times-" [serialports] "Com1" = "/dev/ttyS0" "Com2" = "/dev/ttyS1" "Com3" = "/dev/modem,38400" "Com4" = "/dev/modem" [parallelports] "Lpt1" = "/dev/lp0" [spooler] "LPT1:" = "|lpr" "LPT2:" = "|gs -sDEVICE=bj200 -sOutputFile=/tmp/fred -q -" "LPT3:" = "/dev/lp3" [ports] ;read=0x779,0x379,0x280-0x2a0 ;write=0x779,0x379,0x280-0x2a0 [spy] "Exclude" = "WM_SIZE;WM_TIMER;" [registry] ; Paths must be given in /dir/dir/file.reg format. ; Wine will not understand dos file names here... ;These are all booleans. Y/y/T/t/1 are true, N/n/F/f/0 are false. ;Defaults are read all, write to Home ; Global registries (stored in /etc) "LoadGlobalRegistryFiles" = "Y" ; Home registries (stored in ~user/.wine/) "LoadHomeRegistryFiles" = "Y" ; Load Windows registries from the Windows directory "LoadWindowsRegistryFiles" = "Y" ; TRY to write all changes to home registries "WritetoHomeRegistryFiles" = "Y" ; Use new file format "UseNewFormat" = "Y" ; Registry periodic save timeout in seconds ; PeriodicSave=600 ; Save only modified keys "SaveOnlyUpdatedKeys" = "Y" [Tweak.Layout] ;; WineLook=xxx (supported styles are 'Win31'(default), 'Win95', 'Win98') "WineLook" = "Win95" [programs] "Default" = "" "Startup" = "" [Console] ;Drivers=tty ;XtermProg=nxterm ;InitialRows=25 ;InitialColumns=80 ;TerminalType=nxterm [Clipboard] "ClearAllSelections" = "0" "PersistentSelection" = "1" # </wineconf>

April 22, 2001

Re: Virtual memory under Win95

by Dmitry Timoshkov

"Rein Klazes" <rklazes(a)xs4all.nl> wrote: > win95 on a vmware machine. > > H:\>test > hMapping = 0005 > p = 826DB000 > VirtualQuery(826DB000) ret=0x1c > BaseAddress = 826DB000 > AllocationBase = 826DB000 > AllocationProtect = 0x00000001 > RegionSize = 0x0400f000 > State = 00002000 > Protect = 00000001 > Type = 00020000 This means that Win95/98 doesn't free region allocated with SEC_RESERVE flag set. Could you please test other SEC_ flags? Is the result the same?

April 21, 2001