wine-devel

wine-devel@winehq.org

84463 discussions

Re: recognize Unix-style hidden files
by Alexandre Julliard 14 Sep '02

14 Sep '02

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > The semantics associated in Unix with files starting with > a . is that they are hidden, *exactly* like the hidden DOS > files. We should mark them as such. > > We're lucky in that the DOS world does not use files that > only have extension, so we have no semantical conflict. I don't think I agree with that. Maybe in the days of 8.3 files yes, but nowadays Windows apps can create files starting with a dot, and they don't expect these files to be hidden. Also hidden files are much harder to access under Windows than dot files under Unix, so I'm not sure it would really be better for the user. -- Alexandre Julliard julliard(a)winehq.com

5 12

Press: LinuxPlanet makes a great case for Wine
by Francois Gouget 14 Sep '02

14 Sep '02

(and reviews CrossOver Office 1.2 too :-) * August 29, 2002 - LinuxPlanet CrossOver Office: Cutting to the Quicken http://www.linuxplanet.com/linuxplanet/reviews/4405/1/ -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

1 0

Re: wine/ dlls/ntdll/Makefile.in win32/device.c me ...
by Dimitrie O. Paun 13 Sep '02

13 Sep '02

On September 13, 2002 02:52 pm, Alexandre Julliard wrote: > Log message: > Copied the registry functions needed by VMM into device.c and got rid > of memory/registry.c. Hmm, this is painful. Why and how long do we have to support Win95 advapi32? -- Dimi.

2 2

Re: Re:can windows be reparented?
by Dmitry Timoshkov 13 Sep '02

13 Sep '02

<us(a)the-edmeades.demon.co.uk> wrote: > To be honest I never investigated further once I commented out the SetParent call, > as I was continuing to fix oleaut32 and left the gui side to someone else! > > I know it was being called in the failing case, and removing it allowed the > windows to pop up, BUT they were still wrong as you could access the 'parent' > whereas you should not be able to Could you please test patch posted by Bill Medland to wine-patches today? It's not entirely correct though. My tests show that SetWindowLong(GWL_HWNDPARENT) call changes simultaneously both parent and owner for top level windows and returns old value (not sure old owner or parent it is). But top level windows created by Visual Vasic are special: they have no parent, but only owner according to Spy++. In my tests I can't reproduce it yet. A bit of investigation of Wine source revealed that some places use GetAncestor(hwnd, GA_PARENT), while others use GetParent(hwnd). Since their behaviour is different in respect of top level and child windows, some major clean up in that area in Wine is needed. -- Dmitry.

4 5

Winemaker broken?
by steve.lustbader＠philips.com 13 Sep '02

13 Sep '02

Winemaker doesn't work in the latest CVS. When I run it, it tells me: Global symbol "$app_name" requires explicit package name at /usr/local/bin/winemaker line 1674. Execution of /usr/local/bin/winemaker aborted due to compilation errors. It worked as of Sept 10. -Steve

2 2

configure and then make distclean
by Shachar Shemesh 13 Sep '02

13 Sep '02

Hi, For some strange reason (well, maybe not strange), I cannot run "make distclean" unless the make files are up to date. Is there a reason for this, or is this just a result of a check at the very begining of the makefile? It seems rather strange to me to do "./configure && make distclean; ./configure && make depend && make". Shachar P.S. No, I am not doing this every single time.

2 1

Re: Winemaker: improved MSVCRT support
by Francois Gouget 13 Sep '02

13 Sep '02

On 13 Sep 2002, Martin Wilck wrote: [...] > + if ($dllname =~ /^msvcrt\.dll$/) { You can also say 'if ($dllname eq "msvcrt.dll")'. Great work on winemaker :-) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

1 0

Re: Improved MoveFileEx() Patch
by Huw Davies 13 Sep '02

13 Sep '02

On Fri, Sep 13, 2002 at 04:50:47PM +0200, Martin Wilck wrote: > Index: files/file.c > =================================================================== > RCS file: /home/wine/wine/files/file.c,v > retrieving revision 1.160 > diff -u -r1.160 file.c > --- files/file.c 12 Sep 2002 22:28:01 -0000 1.160 > +++ files/file.c 13 Sep 2002 14:26:47 -0000 > @@ -2579,6 +2579,7 @@ > { > DOS_FULL_NAME full_name1, full_name2; > HANDLE hFile; > + DWORD attr = INVALID_FILE_ATTRIBUTES; > > TRACE("(%s,%s,%04lx)\n", debugstr_w(fn1), debugstr_w(fn2), flag); > > @@ -2619,8 +2620,7 @@ > /* target exists, check if we may overwrite */ > if (!(flag & MOVEFILE_REPLACE_EXISTING)) > { > - /* FIXME: Use right error code */ > - SetLastError( ERROR_ACCESS_DENIED ); > + SetLastError( ERROR_FILE_EXISTS ); > return FALSE; > } > } > @@ -2647,17 +2647,17 @@ > return FILE_AddBootRenameEntry( fn1, fn2, flag ); > } > > + attr = GetFileAttributesA( full_name1.long_name ); Any reason why you don't use: attr = GetFileAttributesW( fn1 ); here? I've seen cases that I've not had time to investigate where the former version fails. Huw. -- Huw Davies huw(a)codeweavers.com

2 1

Shell icons - legal
by Jacek Bator 13 Sep '02

13 Sep '02

Hello! I realy don't like icons which are currently in shell32.dll. I've created few replacement icons from there. They are much more simillar to win95,98 icons ... but not exactly the same. I want to confirm that my work will not be wasted. ---- Original icons from Windows shell32.dll can't be inserted in wine dll because of legal issues (design or something). ----- If I'm wrong let me know. Jacek Bator jbator(a)ecommercelogic.com

1 0

WM_PAINT disappeared
by Fabian Cenedese 13 Sep '02

13 Sep '02

Hi all I have a problem with my MFC-MDI-app. There are some other windows docked in the main window. The problem now is that they don't get painted. I end up with an app-window with some areas that never get updated. I first tried with tracing but I never saw anything wrong. Now I logged in my child window (CIXDockWnd) all messages it gets. This is what happens at creation in Windows: CMainFrame::OnCreate CIXDockWnd: -WM_NCCREATE -WM_NCCALCSIZE -WM_CREATE -WM_SIZE -WM_MOVE .. (some other stuff) -WM_WINDOWPOSCHANGING -WM_NCCALCSIZE -WM_WINDOWPOSCHANGED -WM_SIZE -WM_SHOWWINDOW CImdApp::InitInstance: Call ShowWindow CImdApp::InitInstance: Call UpdateWindow CIXDockWnd: -WM_PAINT (*) -WM_NCPAINT (*) CImdApp::InitInstance: Call SetFocus CIXAppFrame::OnWindowPosChanged CIXDockWnd: -WM_PAINT (*) -WM_NCPAINT (*) -WM_ERASEBKGND (*) IDLE_UPDATE Here the window is finished and visible, waiting for actions. In Wine though the paint messages of the child window (*) never show up, it stays clear. I don't know now if this is a problem in message routing (I don't think so as all other messages come through) or if these messages aren't sent at all. To investigate this can somebody point me to directions where these messages should be generated? Thanks bye Fabi

1 0

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