Re: --dll buggy behaviour ?
Hi! Raul Dias wrote: > I set the default DllOverrides and the AppDefaults\\acmesetup.exe\\DllOverrides to > "comctl32"="builtin" > "commctrl"="builtin" > > and --dll comctl32,commctrl=b > > acmesetup.exe still loads its own comctl32.dll Maybe it's just a typo, but isn't it "acmsetup.exe" and not "acmesetup.exe"? Looking in the cab-files of an IE6 setup cd, I only see "acmsetup"... Philipp
Re: --dll buggy behaviour ?
Raul Dias <[EMAIL PROTECTED]> writes: > However I have launched the instller with: > wine --dll comctl32,commctrl=b ie5setup.exe > > In my config file however, I have the load order as > "native, builtin" for both dlls. > > Is it possible that the --dll command line argument is not > valid for subprocess/forks from the lauched process? The -dll argument is passed to child processes. However the problem in your case is that the dll is not loaded from the standard directory, so it doesn't match the default loadorder. You should either specify the full dll path explicitly, or use a wildcard entry like this: "*comctl32" = "builtin" -- Alexandre Julliard [EMAIL PROTECTED]
Re: extremely simple borland C builder app hangs
On Sun, Aug 25, 2002 at 09:03:31PM +0200, Sylvain Petreolle wrote: > > > fixme:commctrl:FlatSB_SetScrollProp stub > > fixme:commctrl:InitializeFlatSB stub > did you look at MSDN if these 2 stubs aren't the cause of your problem > ? This shouldn't be a problem at all because FlatScrollBar controll defaults to the ScrollBar controll if the FlatScrollBar wasn't initialized. This behaviour is documented by msdn. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg11345/pgp0.pgp Description: PGP signature
Re: IDA stopped working
Shachar Shemesh <[EMAIL PROTECTED]> writes: > Trying to run IDA with a kernel without grsecurity indeed works. > > Can anyone explain why the security patches block the 0040 address > from being used? It's because the security patches map standard libraries like libc at this address (the idea is to make pointers to libc routines contain a 0 byte to make it harder to use them in string buffer overflows). -- Alexandre Julliard [EMAIL PROTECTED]
Re: can windows be reparented? (Buig 825)
"Bill Medland" <[EMAIL PROTECTED]> writes: > Alexandre > > Do you intend accepting the patch; I think it is a reasonable first step and > I am not intending jumping into the focus areas (at least not for a while). Sorry about the delay, I was on a vacation this week. I want to get to the bottom of this thing first, but I'll definitely apply this or a similar patch. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Question about unix path request in 2 of the wine dlls
Steven Edwards <[EMAIL PROTECTED]> writes: > in urlmon umon.c calls cabextract for by requesting the unix path via >wine_get_unix_file_name and > in shell32 shelllink.c get_unix_file_name is used in a few locations. Does anyone >have a > suggestion on a clean simple way to handle both of these on non-nix platforms? Can >this be moved > to libwine? Probably the right way is to use GetProcAddress to get a pointer to wine_get_unix_file_name, and simply skip the call if the function doesn't exist, this should do the right thing in all cases. -- Alexandre Julliard [EMAIL PROTECTED]
Re: REQUEST: symlinks behaviour change
oi, <[EMAIL PROTECTED]> wrote: >You're right for benefits. >But will wine have the same behavior as before ? >In your example, the symlink for regsrv32 is replaced. >We could have a functionnality loss : will the regsrv32 still be >built-in without its symlink ? No. It won;t be builtin. It will be a native regsrv32.exe. It is important to note that if I have ran IE installer as root (as root owns /usr/lib/wine/regsrv32.exe.so in my system), the installation would have overwritten this file and any fake windows tree which symlinks to it (I have a few) would be using the native version instead of the builtin. > >> However, some applications needs to replace this files. >> >> I noted this with the Internet Explorer Installer (5.01 sp1 and 6.0). >> If it cannot >> replace the c:\windows\system\regsrv32.exe file it will abort. >> >> However, as the c:\windows\system\regsrv32.exe is a symlink and wine >> has permition >> to move/delete this symlink, I would link to suggest that wine >> first delete the symlink file when an application tries to write on >> it. >> []'s Raul Dias
Re: --dll buggy behaviour ?
Oi, Eric Pouech <[EMAIL PROTECTED]> wrote: >> I agree, but what do you need to write in order to change the dlls for >> a built-in application ? >> A question was already asked on the list, but no valuable answer was >> found. >> The builtin application chosen was wcmd. >wcmd.exe should work. in fact, this should be inserted in the wine >config file which will populate dynamically the registry (writting >directly to the registry files won't work. Why not? I was thinking that this would be a good way to add specific apps overrides to the global registry (thru regapi). > >for example, add this to ~/.wine/config to run shell32/shell as native >by default > >[AppDefaults\\wcmd.exe\\DllOverrides] >"shell32"="n,b" >"shell"="n,b" > >(see documentation/samples/config for more details and examples) In my original issue (with IE 5 installer), I set the default DllOverrides and the AppDefaults\\acmesetup.exe\\DllOverrides to "comctl32"="builtin" "commctrl"="builtin" and --dll comctl32,commctrl=b acmesetup.exe still loads its own comctl32.dll The only way in this situation to get IE 5 installed is to use a native commctrl.dll. I don't know the win32 api too well. However if it is possible for an application to use its dll (and override the config) which debugmsg channel will show this? > >A+ > []'s Raul Dias
Re: REQUEST: symlinks behaviour change
You're right for benefits. But will wine have the same behavior as before ? In your example, the symlink for regsrv32 is replaced. We could have a functionnality loss : will the regsrv32 still be built-in without its symlink ? > However, some applications needs to replace this files. > > I noted this with the Internet Explorer Installer (5.01 sp1 and 6.0). > If it cannot > replace the c:\windows\system\regsrv32.exe file it will abort. > > However, as the c:\windows\system\regsrv32.exe is a symlink and wine > has permition > to move/delete this symlink, I would link to suggest that wine > first delete the symlink file when an application tries to write on > it. > ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: extremely simple borland C builder app hangs
> fixme:commctrl:FlatSB_SetScrollProp stub > fixme:commctrl:InitializeFlatSB stub did you look at MSDN if these 2 stubs aren't the cause of your problem ? ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: Wine Hides On-board RAM
On Sun, Aug 25, 2002 at 08:17:09AM -0400, Ian D. Stewart wrote: > On 2002.08.18 12:21 Andreas Mohr wrote: > > On Sun, Aug 18, 2002 at 11:32:54AM -0400, Ian D. Stewart wrote: > > > After running Wine for awhile, /proc/meminfo reports MemTotal as > > 32680 > > > kb. The system performs as if it only had 32 MB of RAM. A reboot > > of > > > the system resets total memory to the proper value. > > > > > > My question is: > > > > > > 1) Has anybody else encountered this? > > > 2) Does anyone know what causes this, or better yet how to avoid it? > > > 3) Is there anyway to recover the lost RAM short of a reboot? > > > > Huh ? This is very, very, VERY strange ! > > Something like this should never happen. > > Are you sure it's caused by Wine only, or maybe it is due to faulty > > memory > > instead ? (and thus the board/Linux notices that only 32MB are useable > > and resorts to accessing 32MB only). > > Well I can't say with absolute certainty that it's caused by Wine, but > the system runs without any problems for extended periods of time so > long as I don't run Wine, and consistently 'loses' memory when I *do* > run wine. > > I don't know exactly what's going on. I do know that there appears to > be some sort of threshold that is reached at which point the memory > hiding occurs (e.g., the same issue arises whether I run Wine for 5 > hours at one shot or for 30 minutes a day for 10 days) and the > threshold isn't 'reset' until I reboot. > > > > > Again, I'm utterly puzzled when hearing such a story. > > Or maybe Wine accesses some Linux memory management function in some > > way > > that causes Linux to tamper with the value for some reason ? > > This wouldn't be the first time that Wine is the only program to > > reveal > > some severe bug in Linux memory management... > > > > Definitely try upgrading your kernel, too. > > I have no problem with upgrading, but I would like to know *why* I am > upgrading (i.e., what bug is causing the problem, and how does the new > kernel address the bug). To do otherwise strikes me as being > equivelant to the tendency in the Windows community whenever something > odd happens. *sigh* You're definitely not of the easy kind of people, are you ? ;-) A lot of people would just upgrade and be happy in case the bug is fixed, but you... :) Well, if you're so eager to learn what the problem is, then I'd suggest to get your hands pitch black dirty immediately ;-) Find out where /proc/meminfo gets fed with values, then find out which part messes with the MemTotal value in any way. Hmm, arch/i386/mm/init.c/si_meminfo() sounds like a sure winner. I'd suggest looking for the totalram_pages variable (add logging whenever that one gets modified in some way). OTOH I don't see any place where there is a direct assignment of that variable. Hmm, where does that variable even get initialized then ??? (well, probably declaration auto initialization then) Oh well, good luck ! ;) -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: Wine Hides On-board RAM
On 2002.08.18 12:21 Andreas Mohr wrote: > On Sun, Aug 18, 2002 at 11:32:54AM -0400, Ian D. Stewart wrote: > > I have recently noticed an unusual side-effect of running Wine. > When I > > first start up my system, /proc/meminfo reports MemTotal as 256892 > kb. > > After running Wine for awhile, /proc/meminfo reports MemTotal as > 32680 > > kb. The system performs as if it only had 32 MB of RAM. A reboot > of > > the system resets total memory to the proper value. > > > > My question is: > > > > 1) Has anybody else encountered this? > > 2) Does anyone know what causes this, or better yet how to avoid it? > > 3) Is there anyway to recover the lost RAM short of a reboot? > > Huh ? This is very, very, VERY strange ! > Something like this should never happen. > Are you sure it's caused by Wine only, or maybe it is due to faulty > memory > instead ? (and thus the board/Linux notices that only 32MB are useable > and resorts to accessing 32MB only). Well I can't say with absolute certainty that it's caused by Wine, but the system runs without any problems for extended periods of time so long as I don't run Wine, and consistently 'loses' memory when I *do* run wine. I don't know exactly what's going on. I do know that there appears to be some sort of threshold that is reached at which point the memory hiding occurs (e.g., the same issue arises whether I run Wine for 5 hours at one shot or for 30 minutes a day for 10 days) and the threshold isn't 'reset' until I reboot. > > Again, I'm utterly puzzled when hearing such a story. > Or maybe Wine accesses some Linux memory management function in some > way > that causes Linux to tamper with the value for some reason ? > This wouldn't be the first time that Wine is the only program to > reveal > some severe bug in Linux memory management... > > Definitely try upgrading your kernel, too. I have no problem with upgrading, but I would like to know *why* I am upgrading (i.e., what bug is causing the problem, and how does the new kernel address the bug). To do otherwise strikes me as being equivelant to the tendency in the Windows community whenever something odd happens. Thanx for the input, Andreas. Ian
Re: comctl32.dll compile on WinXP
Hola Sorry about being so late in getting back to you but I've been busy. I'm going to adapt your test for mingw and commit it to the reactos tree so I can test our comctl32.dll. If you are going to do more work on porting the wine dlls to windows please use the diff -u format Thanks Steven --- Zoltán_Nagy <[EMAIL PROTECTED]> wrote: > Dear Wine, > > I made two changes (wine 10.07.2002.) in your wine software > > First: > controls/edit.c > If you select a text area width mouse, then caret is not moved (like Windows). > The follow code solution the problem: > > end of EDIT_WM_MouseMove(): > EDIT_SetCaretPos(hwnd,es,es->selection_end,es->flags & EF_AFTER_WRAP); > return 0; > } > > > Second: > How can I build comctl32.dll (or other dll) with MS Visual C++ .NET (on WinXP)? > This is not problem (tested on WinXP): > > 1. please create a directory (examlpe test1) > 2. please create an INCLUDE directory (examlpe test1\INCLUDE) > 3. please copy the full wine include files here (test1\inlude\*.*) > 3. unzip the full.zip into test1 directory (this changes more include files) > 4. Open width MS Visual C++ .net the test1\dlls\testcomctl32\testcomctl32.sln file > 5. Compile project (F7). No panic, if you see very lot of warning (1679 pc.). (if >not success > the compile, then maybe problem width include files) > > But I have a big problem, if I use the testcomctl32.dll from Windows aplication, then > RegisterClass function fail width 1410 error code (Class already exists), therefore >I renamed > the name of classes (ex. msctls_progress32 -> wine_msctls_progress32). > > I made two examle, how to use the testcomctl32.dll? > In the BIN directory can be found the TESTCOM.EXE (this use the WINE comctl32.dll) >and > TESTCOMWINDOWS.EXE (use the MS comctl32.dll). > > > > Best Regards, > > Zoltan Nagy > form Hungary > > [EMAIL PROTECTED] > or > [EMAIL PROTECTED] > or > [EMAIL PROTECTED] > > ATTACHMENT part 2 application/x-zip-compressed name=FULL.ZIP __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com
Re: --dll buggy behaviour ?
> I agree, but what do you need to write in order to change the dlls for > a built-in application ? > A question was already asked on the list, but no valuable answer was > found. > The builtin application chosen was wcmd. wcmd.exe should work. in fact, this should be inserted in the wine config file which will populate dynamically the registry (writting directly to the registry files won't work. for example, add this to ~/.wine/config to run shell32/shell as native by default [AppDefaults\\wcmd.exe\\DllOverrides] "shell32"="n,b" "shell"="n,b" (see documentation/samples/config for more details and examples) A+
