which is why I've never seen this before.)
> The lines involved seem unchanged since Martin Fuchs'
> winefile code was merged back in 2002.
>
> Conditional jump or move depends on uninitialised value(s)
> at calc_widths (winefile.c:2711)
> by create_tree_window (winef
Hello,
what about asking the developer where he got his information? ;-)
If I remember correctly, I found this logoff dialog function using
Google on one of those "undocumented Windows 95" web pages when adding
it to the original ROS Explorer.
Regards,
Martin
Am 23.05.2008 um 06:37 s
TED]>
Date: Mon Jul 23 22:25:20 2007 +0200
winefile: Replace malloc with HeapAlloc.
- Entry* entry = (Entry*) malloc(sizeof(Entry));
+ Entry* entry = HeapAlloc(GetProcessHeap(), 0, sizeof(Entry));
- free(entry);
+ HeapFree(GetProcessHeap(), 0, entry);
}
--
Hi,
any hint why this patch was not yet applied?
Regards,
Martin
On 13.05.2007 19:04:25 Martin Fuchs wrote:
Changelog:
implement SheGetDirA/W and SheChangeDirA/W in shell32
This functions are needed for the good old winfile.exe of NT4.
Index: dlls/shell32/shlfileop.c
On 13.06.2006 12:22:57 Rick Opper wrote:
> hi,
> Like many wine users, I'm having trouble with programs calling the
> GetFolderAttributes... I've seen your patches and was wondering if it
> would be possible to download the pre-patched DLLs from somewhere.
What problems are there exactly?
2006/3/19, Alexandre Julliard <[EMAIL PROTECTED]>:
> I think these windowsx macros are confusing things more than helping,
> especially since they don't look like macros. It's better to have
> explicit SendMessage calls than some pseudo function calls, it makes
> much more obvious what's going on,
2006/3/18, Robert Shearman <[EMAIL PROTECTED]>:
> Mike McCormack wrote:
>
> >
> > Martin Fuchs wrote:
> >
> >> "Eliminating" windowsx.h sounds like you consider this header file a
> >> bad thing.
> >> I don't think s
Hi,
"Eliminating" windowsx.h sounds like you consider this header file a bad thing.
I don't think so - it provides a bunch of very usefull type safe macro
definitions.
(SelectFont, ListBox_SetSel, Button_SetCheck, ...)
I understand you want to eliminate some useless warnings printed by
newer GCC
Hello,
> This patch is giving me trouble:
does the following patch help to solve your problem?
Regards,
Martin
Index: shlfolder.c
===
RCS file: /home/wine/wine/dlls/shell32/shlfolder.c,v
retrieving revision 1.110
diff -u -p -d
is there anything wrong with this patch to get Photoshop launching again?
On 31.01.2006 22:58:34 Martin Fuchs wrote:
> Changelog:
> - retrieve file attributes using SHGetPathFromIDListW() when they are not
> already
> present in the internal PIDL structures
> - correct docu
Hello Steven,
> Alexandre did not like the needed changes required to add support for
> this but I figured I would throw it out for debate anyway in case
> anyone else can make him change his mind (duck). The issue is he does
> not like needing a single header per-program or per dll. After doing
>
On 07.01.2006 17:52:04 Vitaliy Margolen wrote:
> Saturday, January 7, 2006, 9:30:34 AM, Martin Fuchs wrote:
> > Changelog:
> > - fix folder icon index when read from registry
> > - change "DWORD dwNr" into "int icon_idx" at several places
> Any rea
Any thing wrong with this patch?
On 31.12.2005 21:31:25 Martin Fuchs wrote:
> Changelog:
> fix folder icon index when read from registry
> Index: folders.c
> ===
> RCS file: /home/wine/wine/dlls/shell32/folders.c
> Well, I think having some description of what the patch is about is
> more useful than a truncated file list, but if the general feeling is
> that the file list is better I can put this back.
What about all three informations:
a.) author
b.) affected directory, like "[dlls/ole32]"
c.) beginning
Hello Mike,
On 03.11.2005 07:24:42 Mike McCormack wrote:
> ChangeLog:
> Pass the correct verb.
> Add a space between extra parameters.
> Wait for ShellExecute to complete.
[...]
> if( ShellExecuteExW( &sei ) )
>+{
>+if (sei.hProcess)
>+WaitForSingleObject(sei.hProcess
Hello Michael,
> Those are default flags, for the case that HCR_GetFolderAttributes didn't find
> a registry entry. Are you sure those aren't necessary? Perhaps we should push
> them into HCR_GetFolderAttributes, though.
Yes, I am quite sure the change is correct. It doesn't just remove the
follo
> This is because 'LANGUAGE LANG_' statements don't actually change
> code page specified by a previous '#pragma code_page()', therefore
> russian resources get translated to unicode using wrong code page.
> I don't know whether it's an rc bug or a feature. We either need
> to remove '#prag
> > No, I don't need tchar.h in 'unixcalls.c'. I only needed it
> > for 'winefile.c'. The problem is, if I add 'include/msvcrt'
> > to the include path, it is added to both files at the same time.
>
> I see. What about adding a separate rule to Makefile.in just for
> unixcalls.c and omit that file
> > I thought it would be enough just to use "--ptr" to go back one
> > character in UCS-16 strings. Only MBCS or UTF-8 encoded strings would
> > need such helper functions like CharPrevW()?
>
> IIRC there are these 'surrogate pairs' in which case just --ptr
> will not work correctly:
> http://msd
> > > CharUpperW() is towupper().
> >
> > Well, CharUpper() works with strings instead of characters. So that's
> > what I changed in the pattern matching function.
>
> No, it also works on characters. Check MSDN. ;)
# [in/out] Pointer to a null-terminated string or specifies a single character.
> > I can't find a replacement for wcsrchr() in the windows API, so I have to
> > include my own implementation in the source. There is also no equivalent of
> > towupper(), so I have to change the pattern matching function a bit.
>
> wcsrchr() is problematic, but can probalby be done with CharP
Hello Ralf,
> I assume you only need include/msvcrt for unixcalls.c to be able to
> include tchar.h. I assume the reason why tchar.h only works with msvcrt
No, I don't need tchar.h in 'unixcalls.c'. I only needed it for 'winefile.c'.
The problem is, if I add 'include/msvcrt' to the include path,
Dmitry,
> > switch winefile to UNICODE mode
>
> Why to go through all this pain and not just make it unicode
> only?
currently it's impossible to compile winefile in UNICODE mode with
Wine without some extra rule for unixcalls.c in the Makefile. I tried
it even without using any TCHAR functions
22 Jun 2005 22:37:34 +0200, Alexandre Julliard <[EMAIL PROTECTED]>:
> Martin Fuchs <[EMAIL PROTECTED]> writes:
>
> > Let me change the question: Why should one use Unicode on those
> > systems at all? They don't support Unicode file systems - so there are
22 Jun 2005 10:36:22 +0200, Alexandre Julliard <[EMAIL PROTECTED]>:
> Martin Fuchs <[EMAIL PROTECTED]> writes:
>
> > Sure, is not designed to be used "internally" in Wine. But
> > the point is,
> > I would like to maintain Winefile such, that
22 Jun 2005 10:56:18 +0200, Alexandre Julliard <[EMAIL PROTECTED]>:
> "Ralf Reiterer" <[EMAIL PROTECTED]> writes:
>
> > So I really think Wine has to support the TCHAR type and all
> > associated functions/macros to stay as close to the Windows
> > API as possible.
>
> Wine obviously supports TCH
> > The pure existence of in the Wine code base
> > shows me, Wine is aimed to support TCHARs. So why don't you
> > want to properly activate its functionality and take Winefile
> > as an example how to use it?
> > ...
> > I know, I won't be able to convince you. Any one out there to
> > support m
On 21.06.2005 23:44:21 Frank Richter wrote:
> On 21.06.2005 23:12, Martin Fuchs wrote:
> > The pure existence of in the Wine code base shows
> > me, Wine is aimed to support TCHARs.
> It may also just show that Wine wants to be compatible with existing sources
>
Hi,
> This stuff is getting uglier all the time. Please consider converting
> to Unicode properly and getting rid of all the TCHAR crap. I know the
> goal is to show how to use it, but at this point all it does is
> demonstrate why using TCHAR is a really bad idea. The way this is
> going pretty s
t; On Tue, 2005-06-21 at 17:57 +0200, Martin Fuchs wrote:
> > Hi James,
> >
> > > Last night Martin Fuchs suggested that we look into using ReactOS's
> > > registry format in order to be compatible with Windows registry
> > > databases. I have the latest
Hi James,
> Last night Martin Fuchs suggested that we look into using ReactOS's
> registry format in order to be compatible with Windows registry
> databases. I have the latest release of ReactOS running on QEMU on my
> box, so I checked it out. Basically, they're using the
tchar.h internally
#endif
-#if defined(_UNICODE) || defined(_MBCS)
-#error You must use msvcrt when building in Unicode/MBCS mode
-#endif
-
#ifdef __cplusplus
extern "C" {
#endif
Index: programs/winefile/unixcalls.c
--- /dev/null 2004-04-06 15:27:52.0 +0200
+++ programs/w
Hi Marcelo,
2005/6/20, Marcelo Duarte <[EMAIL PROTECTED]>:
> I don´t understand something or winefile can use Michael Jung´s unixfs
> namespace extension?
The difference is: The unixfs namespace extension is implemented in
shell namespace. This is a quite huge overhead compared to directly
access
2005/6/19, James Liggett <[EMAIL PROTECTED]>:
> Hi Brad,
> I've been following you discussion about wine's registry format, and I
> find it interesting. I gave it some thought, I have have an idea. Have
> you thought about using XML as a potential format? Since the registry is
> a non-relational tr
> > Changelog:
> > switch winefile to UNICODE mode
> Why to go through all this pain and not just make it unicode
> only?
First of all: Winefile was designed to be usable both in ANSI and UNICODE
mode from the begin on, and I won't remove this functionality. So you can
build and use it also on 8
Is there some problem with this patch?Seems it's not yet committed, and I could not find any answer mail about it.
http://www.winehq.org/hypermail/wine-patches/2005/04/0127.html
On 12.04.2005 13:13:27 Huw D M Davies wrote:> This depends on 'shell32: Add unicode pidl type'
> Huw Davies <[EM
> Why is this needed?
> Doesn't HeapAlloc work on any 'Win32' platform?
I want to avoid calling heap allocation functions.
Using alloca() is slightly lighter.
Regards,
Martin
Hi,
I want to merge some Robert Dickenson's version of winfile (derived from the
old winefile code in 2002) in the next time into winefile. At the same time I
want to keep the code it in sync between the ReactOS code base and Wine.
What do you think about splitting the source file into several
> If you wrote your own version of Calc it may be an amusing thing to add
> to Wine. We have a minesweeper clone, after all, and I'm sure that the
> reactos guys would appreciate it.
Well, there is already a winecalc in ReactOS.
Has this new version some additional features?
Hello,
can anyone explain to me, what's the exact reason for the following
error message in wine/include/tchar.h:
#if defined(_UNICODE) || defined(_MBCS)
#error You must use msvcrt when building in Unicode/MBCS mode
#endif
It disallows inclusion of this header file when using the
_UNICODE defi
Am Donnerstag, 7. Oktober 2004 12:41 schrieb Paul Millar:
> Hi,
>
> Looks like one of last night's patches broke cross-building (at least for
> me).
>
> -- Forwarded Message --
>
> Subject: Cron <[EMAIL PROTECTED]> $HOME/Production/cronCrossBuild 10:00
> Date: Thursday 07 October
> Of course it does if you call the Unicode functions. Unix systems
> don't store the filenames in Unicode but use codepages. This codepage
> may be UTF-8 which is equivalent to Unicode or some other codepage.
> Wine takes care of converting from that codepage to Unicode.
> There's no Unix func
Hi Francois,
> > Winefile was always UNICODE/ANSI-capable by using TCHAR, TEXT(),
> > and the right functions. Currently ReactOS is using the UNCODE version,
> > and Wine is using the ANSI version. Both without problems.
> I think it's wrong that Wine's winefile is ANSI: doesn't that mean we'll
> > Come on - is this really that difficult? ;-)
> > And as you see, I will maintain it for you.
> The problem is not whether you are maintaining it or not.
Well, you began to talk about maintaining the code:
>> By using TCHAR you actually hide the problem and make the code
>> very hard to main
> "Martin Fuchs" <[EMAIL PROTECTED]> wrote:
> > - use TCHAR to make the code UNICODE compatible
> By using TCHAR you actually hide the problem and make the code
> very hard to maintain. What is the purpose of that in Wine or
> ReactOS? Why don't you u
Hello Francois,
> It looks like it does not find the $wine_dir declaration. We are
> supposed to import it from the config module which in fact imports it
> from the setup module. Does it work better if you edit
> tools/winapi/msvcmaker as follows?
It seems, that's not enough. Then it can't fi
OK, here is the next problem.
The tool msvcmaker prints the following error messages:
$ tools/winapi/msvcmaker
Global symbol "$wine_dir" requires explicit package name at tools/winapi/msvcmaker
line 52.
Global symbol "$wine_dir" requires explicit package name at tools/winapi/msvcmaker
line 116.
Hi Hans,
> Wait, I see now that there's another use of .previous which is protected
> differently. The path below may solve your problem.
thanks - I am now using the following change:
Changelog:
Don't use ".previous" for MinGW and Cygwin builds
Index: port.h
==
> It looks like you are mixing includes from Wine and Mingw, that's not
> going to work well. My guess is that you didn't run make from the
> top-level directory, so Wine didn't get a chance to build its includes
> and Mingw falls back to the w32api ones.
I tried building from the top, from libs/w
Hello,
when trying to compile WINE using Cygwin I am getting errors such as: (this example
for wine/programs/notepad)
gcc -c -I. -I. -I../../include -I../../include -I../../include/msvcrt
-DNO_LIBWINE_PORT -D_REENTRANT -Wall -pipe -mprefe
rred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wp
On 27.05.2004 04:09:34 Alexandre Julliard wrote:
> Stefan Leichter <[EMAIL PROTECTED]> writes:
> > before removing the acsii calls from GetAcceptLanguagesW, i like to see
> the
> > results of the attached tests. This will hopefuly save me some work when
> > rewriting the function. The tests pas
Hi Juan,
> Martin wrote:
> > But we could use the expression
> > "MAKE_HRESULT(SEVERITY_ERROR, FACILITY_WIN32,
> > ERROR_FILE_NOT_FOUND)" instead.
>
> A shorter version is
> HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND).
Yes, this would also be a possible solution.
But HRESULT_FROM_WIN32 contains so
13 Apr 2004 20:45:39 -
> > @@ -217,6 +217,7 @@ ISF_MyComputer_fnParseDisplayName (IShel
> > /* do we have an absolute path name ? */
> > else if (PathGetDriveNumberW (lpszDisplayName) >= 0 &&
> lpszDisplayName[2] == (WCHAR) '\\') {
> > szNext = GetNextElementW (lpszDispla
> ...
> Martin> 0x80070002L; /* file not found */ } else { pidlTemp =
> ...
> Don't we have a symbolic error for that?
There is no such constant in winerror.h.
But we could use the expression "MAKE_HRESULT(SEVERITY_ERROR, FACILITY_WIN32,
ERROR_FILE_NOT_FOUND)" instead.
This is also used for
On 09.04.2004 17:15:49 Francois Gouget wrote:
> Well, it's actually worst than that. Just before we have this code:
>
> if (wszCommandline[0]) {
> strcatW(wszApplicationName, wSpace);
> strcatW(wszApplicationName, wszCommandline);
> }
> ...
> /* Else, try to find t
On 09.04.2004 02:03:37 Francois Gouget wrote:
>
> This patch fixes two IE compatibility problems.
>
> The first one is a mundane issue. IE calls ShellExecuteEx with a NULL
> verb. Our implementation fails when it should use some sophisticated
> algorithm described in the MSDN to choose a defaul
> > If you want to do exactly what native shell32 does, you can just drop
> > all the old (non-desktop mode) code and replace it with what my
> > patch wanted to do in desktop mode.
>
> Yes, I realise that. I guess you checked that these are the same
> messages native shell32.dll uses?
Yes, it's
Hello Mike,
> However, we do want native shell32 to work, so it'll be using the same
> protocol.
sure.
> > Well, let's see how far Mike's upcoming rewritten systray can handle this.
> > I may have a look in the new code, and see if I it's possible to do it
> > without knowing about the desktop m
On 29.03.2004 22:49:56 Alexandre Julliard wrote:
> "Martin Fuchs" <[EMAIL PROTECTED]> writes:
>
> > I wrote this for ROS Explorer and tested it running the WIN32 executable
> > with the patched Wine. IMHO this is the only way to get system tray
> > w
> Is there such a thing as a source code visualization tool that makes a
> "map" of a program's source? Kind of like:
>
> main()
> |
> |
> function1()
> /\
>/ \
> func2() func3()
> |
> > Changelog:
> > SHELL_NotifyIcon() implementation for Wine's desktop mode
>
> I'm not sure it makes any sense to do this: the system tray code is on my
> hit list for things to rewrite. It's already been mostly done, the work
> remaining is moving the code into a separate process then using the
> > /* process the IDList */
> > -if ((sei_tmp.fMask & SEE_MASK_INVOKEIDLIST) == SEE_MASK_INVOKEIDLIST)
> /*0x0c*/
> > +if (sei_tmp.fMask & SEE_MASK_INVOKEIDLIST) /* 0x0c: includes
> SEE_MASK_IDLIST */
>
> If you only care about the MASK_IDLIST flag you should check just that
> flag
On 25.03.2004 22:31:59 Dimitrie O. Paun wrote:
> On Thu, 25 Mar 2004, Martin Fuchs wrote:
>
> > OK, now the patch including the "return S_FALSE". :-)
>
> This is why small patches are better than large ones :)
Mhh - if you had accepted the whole patch, I would n
On 25.03.2004 01:00:25 Alexandre Julliard wrote:
> "Martin Fuchs" <[EMAIL PROTECTED]> writes:
>
> > + if (This->bDirty)
> > + return S_OK;
> > +
> > return NOERROR;
>
> S_OK and NOERROR mean the same thing, so this doesn'
On 15.03.2004 23:01:56 Martin Fuchs wrote:
> Well to take up for the ReactOS folks Martin and Ge have done one hell
> of a fine job on shell32 !!
> And they have given every thing back.. Not once but twice!
> As AJ was on vacation at the time and Martin & Ge spent alot of
Alexandre - is there any thing wrong with this patch?
> Changelog:
> - expand environment strings in command, parameter and directory strings of
> ShellExecuteExW32()
My follow-up patches are blocked by this not yet committed patch.
> > Changelog:
> > correct parameter type for SafeArrayCreateVector() and
> SafeArrayCreateVectorEx() from ULONG to UINT
>
> The Microsoft headers have ULONG here, what headers are you using?
Yes, you are right. In the headers there is "ULONG".
I looked in the MSDN documentation:
http://msdn.mic
Hello,
> > This patch broke the installation of IE6.
> >
> > When running the command below during installation of IE6, a pathname is
> > scribbled over the stack...
> >
> > C:\windows\inf\unregmp2.exe /Shortcuts /IE5 /RegExts
> >
> > Any ideas why?
I see you found and could solve the problem
> > Changelog:
> > - don't link directly to NTDLL; use MultiByteToWideChar() instead of
> RtlCreateUnicodeStringFromAsciiz()
>
> Why do you need that?
RtlCreateUnicodeStringFromAsciiz() is neither present in MinGW nor in PSDK.
Regards,
Martin
Changelog:
- implemented SHGetRealIDL()
Index: pidl.c
===
RCS file: /home/wine/wine/dlls/shell32/pidl.c,v
retrieving revision 1.96
diff -u -p -d -r1.96 pidl.c
--- pidl.c 18 Jan 2004 22:08:46 - 1.96
+++ pidl.c 20 Ja
On 19.01.2004 18:05:18 Hans Leidekker wrote:
> On Sunday 18 January 2004 18:02, Francois Gouget wrote:
>
> > What about MinGW? It sounds like this test does not compile there
> > either...
>
> Well, it compiles and links, but doesn't link at run-time
> because MinGW's import lib exports these sym
On 18.01.2004 11:52:06 Dmitry Timoshkov wrote:
> "Steven Edwards" <[EMAIL PROTECTED]> wrote:
>
> > I dont know if anyone else has tried this but when I try to add
> > resources to a *.rc I get a error. This patch fixes it.
>
> What kind of error do you get? I just tried to change an .rc
> and to
other generic app types that may qualify: text editors,
> file managers, whathaveyou.
Why not just configure everything in the registry and use ShellExecute() to
launch the correct applications this way?
--
Martin Fuchs
[EMAIL PROTECTED]
+++ GMX - die erste Adresse für Mail, Message, More
> > There are also a number of unneeded whitespace changes that make the
> > patch larger than it should be.
>
> Yes, I tried to make some functions I had to alter a bit more readable.
> What about running a pretty printer, for example astyle
> (http://astyle.sourceforge.net/)
> on the whole code
On 12.01.2004 01:41:45 Alexandre Julliard wrote:
> "Martin Fuchs" <[EMAIL PROTECTED]> writes:
>
> > Mhh - could you please tell me which "ugly hacks" you are speaking of?
>
> From a quick look at the patch, what I noticed is mostly the ifdefs
> and
> I'm afraid you'll have to do that. There's no way I can put that patch
> in as is, it's way too big and doing way too many different things. It
> also has a number of ugly hacks that will have to be cleaned up.
> Please submit small self-contained patches that do only one thing,
> with a changelo
> Martin, sending a bunch of patches compressed and in one message,
> makes them almost unreviewable but by the most die hards readers
> of wine-patches. It also makes it so much more difficult for
> Alexandre to split them up, match the ChangeLog, review them, etc.
> Please stick to one-(uncompres
Sorry, I forgot to include the new file "shlcpanel.c" into the shell32 patch mail.
Changelog:
- Implementation of control panel folder in shgell namespace
--
Martin Fuchs
[EMAIL PROTECTED]
shlcpanel.patch
Description: Binary data
4E-4F 54 45 50 D.EXE â
..\NOTEP0120: 41 44 2E 45-58 45 0A 00-43 3A 5C 57-49 4E 44
4F AD.EXEâ C:\WINDO0130: 57 53 00 00-00
00
-
-
WS
--Martin Fuchs[EMAIL PROTECTED]
> Hmm..., I KNOW 'SCF_UNICODE' is NOT 0x1000 in the first place, but why do
> you say it's 0x80 ?
>
> Going by the copyrights, Marcus Meissner and Juergen Schmied did the initial
> job, and perhaps one of them put this value.
> I don't know about Juergen, but I have tremendous faith in Marcus (I
Hello,
On 06.01.2004 18:51:16 Subhobroto Sinha wrote:
> I had completed the patch for IPersistFile::Load() and associated functions.
> In the last patch which I had submitted for review here, Mike McCormack had
> pointed out an incorrect assumption that I had made about all locales being
> DB
> Define __WINE__ to enable extensions (spotted by Martin Fuchs).
>
> Patch: http://cvs.winehq.com/patch.py?id=10428
>
> Old revision New revision Changes Path
> 1.4 1.5 +1 -0 wine/programs/winefile/Makefile.in
It's not enough to defin
Hi,
here is the patch to correct the problem.
There have been missing a view initializations of struct SHELLEXECUTEINFO.
This fixes only the crash, which was caused by Winefile.
It does not complete the ShellExecuteEx() implementation.
--
Martin Fuchs
[EMAIL PROTECTED]
Index: winefile.c
e current CVS
version a superfluous "Succeded" message.)
The problem in those shell windows also shows up onnative windows. I will look
into it.
Regards,
Martin
--
Martin Fuchs
[EMAIL PROTECTED]
[Ralf Juengling]
> > What is the status of the include files in msvcrt?
[Alexandre Julliard]
> They should work just fine. Make sure you also import msvcrt if you
> use the headers.
[Ralf Juengling]
> > So my solution to make it compile was to remove wine's
> > 'math.h'. That's why I would say t
On 11.11.2003 22:49:30 Martin Fuchs wrote:
> Changelog:
> implemented flag FWF_DESKTOP for IShellView_fnCreateViewWindow()
Please don't apply this patch. The patch of Filip Navara already contains FWF_DESKTOP
handling.
"user start menu root: %s\n", path);
process_startmenu(path);
}
if (SHGetSpecialFolderPath(0, path, CSIDL_COMMON_STARTMENU, FALSE)) {
printf("common start menu root: %s\n", path);
process_startmenu(path);
}
nd extended memory size?)
>
> Do we have any tools that can demangle MSVC++ symbol names? c++filt won't
> do it unfortunately.
For example depends.exe does this. It translates to:
enum CFSObj::ACCESS CFileFolder::AccessGet(class IInterrupt *,int *)"
--
Martin Fuchs
[EMAIL PROTECTED]
Hello Uwe,
I have merged the tests into dlls/user/tests/win.c and extended them a bit. I tried
them on Win XP and on WIN 98 and had to see, there are some differencies between the
operating systems. So a few tests are commented out with an apropiet comment. Now all
active SetShellWindow tests a
and automatically set to zero.
- If you try to move the window into the foreground by calling SetWindowPos() with
HWND_TOPMOST this call succeedes, but it does not change anything. The window remains
in the background.
--
Martin Fuchs
[EMAIL PROTECTED]#define WIN32_LEAN_AND_MEAN
#incl
On Tue 7. October 2003 22:15, Alexandre Julliard wrote:
> Martin Fuchs <[EMAIL PROTECTED]> writes:
> > When trying to get my explorer clone to work on Wine, I found this way to
> > make it work in Wine's desktop mode. I am also not really sure if this is
> > the on
> > But you did not yet insert the altered focus handling in
> set_active_window()
> > from my patch. Is this just comming next, or is there another particular
> > reason for not doing this?
>
> Well, I'm not convinced we need to do such special handling at all;
> why did you have to add that?
Th
ows: winpos.c
> server : window.c trace.c request.h protocol.def
> include/wine : server_protocol.h
> dlls/user : focus.c
>
> Log message:
> Store the global shell, progman and taskman windows in the server
> (based on a
Here is the complete mail...
Hello,
PETREOLLE Sylvain wrote:
> Can your explorer clone be compiled with Wine sources and/or tools ?
> I have both Windows 2000/XP with latest Cygwin / RedHat Linux environments
> to test it.
Yes, I have put a "Makefile.Wine" into CVS for compiling as Winelib appli
Hello,
PETREOLLE Sylvain wrote:
> Can your explorer clone be compiled with Wine sources and/or tools ?
> I have both Windows 2000/XP with latest Cygwin / RedHat Linux environments
> to test it.
Yes, I have put a "Makefile.Wine" into CVS for compiling as Winelib application. Just
put the explorer
gt;
> > Now I tried once more and found this works:
> > IDI_EXPLORERICONDISCARDABLE res/explorer.ico
> >
> > Why doesn't the standard way with quotation marks work? I think this is a
> > bug and should be corrected in wrc?
>
> Yes that's a bug. I
On Sun 28. September 2003 04:23, Alexandre Julliard wrote:
> Martin Fuchs <[EMAIL PROTECTED]> writes:
> > I tried to compile my explorer as winelib application, and got to this
> > problem: How to compile a resource file, which has no problems with RC or
> > WINDRES w
> > Hmmm Than i don't see any reason to compile program using winelib.
>
> True, there's not much reason to do so other than:
> 1. being able to call Unix functions from your Win32 program
> 2. a warm and fuzzy feeling that you've "ported" the app to Linux :)
You should not forget one big
need at least three times more space as really needed.
I tried to compile my explorer as winelib application, and got to this
problem: How to compile a resource file, which has no problems with RC or
WINDRES with WRC? When inlining all the picture files with bin2res, I get a
really huge RC file.
--
Martin Fuchs
[EMAIL PROTECTED]
On 02.09.2003 22:33:07 Martin Fuchs wrote:
On 02.09.2003 22:07:16 Alexandre Julliard wrote:
> Martin Fuchs <[EMAIL PROTECTED]> writes:
>
> > Changelog:
> > * define interface IDragSourceHelper
> > * define interface IDropTargetHelper
>
> They are already
100 matches
Mail list logo
