h=f07ff7f9819b32437624a320fe3029dd795b7a61
>>
>> Author: Alexandre Julliard
>> Date: Tue Jun 18 11:32:45 2013 +0200
>>
>> winefile: Avoid abbreviations in column names.
>
> Why not remove the "Date" word as they are always dates? Leave only
> &q
rd
> Date: Tue Jun 18 11:32:45 2013 +0200
>
> winefile: Avoid abbreviations in column names.
Why not remove the "Date" word as they are always dates? Leave only
"Creation", "Modification" and "Access". It will help to keep the
column headers short. Are they used in other places?
Best wishes,
Bruno
Am 14.03.2012 19:41, schrieb Alexandre Julliard:
> André Hentschel writes:
>
>> @@ -3973,6 +3973,7 @@ static BOOL prompt_target(Pane* pane, LPWSTR source,
>> LPWSTR target)
>> static IContextMenu2* s_pctxmenu2 = NULL;
>> static IContextMenu3* s_pctxmenu3 = NULL;
>>
>> +#ifndef _NO_EXTENSIONS
André Hentschel writes:
> @@ -3973,6 +3973,7 @@ static BOOL prompt_target(Pane* pane, LPWSTR source,
> LPWSTR target)
> static IContextMenu2* s_pctxmenu2 = NULL;
> static IContextMenu3* s_pctxmenu3 = NULL;
>
> +#ifndef _NO_EXTENSIONS
> static void CtxMenu_reset(void)
> {
> s_pctxmenu
André Hentschel writes:
> @@ -1,10 +1,9 @@
> EXTRADEFS = -D__WINE__
> MODULE= winefile.exe
> -APPMODE = -mwindows -municode
> +APPMODE = -mwindows -municode -mno-cygwin
You can't do that, winefile wants Unix filesystem calls.
--
Alexandre Julliard
julli...@winehq.org
Jerome Leclanche wrote:
> Users who do not understand the meaning of GiB/MiB/kiB are unlikely to
> understand GB/MB/kB. I think the "too geeky" bit is a non-issue.
>
> Personally, I believe kiB is the way to go. Windows is not necessarily
> correct in its usage of kB. Most Linux apps also tend t
;%', '.', '1', 'f', ' ', 'k', 'B',
>> '\0'};
>
> To be totally correct these should actually be 'GiB', 'MiB' and 'kiB'
> (the code divides by powers of 1024). However that may b
27;, 'f', ' ', 'M', 'B', '\0'};
> - static const WCHAR sFmtkB[] = {'%', '.', '1', 'f', ' ', 'k', 'B', '\0'};
To be totally correct these should actually be '
In the resources, and hence in the PO files we have this string:
IDS_TITLEFMT"%s - %s"
I see no way in which this can be meaningfully translated and many ways
in which translators can mess it up. Yet it was moved there by this
commit:
commit 1573382dd6baa48bb825c26faef96a
On Wed, Mar 30, 2011 at 7:46 AM, Francois Gouget wrote:
> They unnecessarily clutter the GUI and are unlikely to ever be implemented.
> ---
>
> As discussed on wine-devel.
> I still left Rename and Create Directory because they are basic
> functions that should really be there (but I won't impleme
A typical scenario:
- download a file with uTorrent
- select "Open containing folder"
- ???
- use a native program to work with the downloaded file
I think, it would be convenient to add a button to start a terminal or
do "xdg-open ."
Hello Ken,
Ken Sharp wrote:
> Australian, British and New Zealand English prefers -ise over -ize
> (strongly so in Aus and NZ).
>
> http://en.wikipedia.org/wiki/En-AU#Spelling
> http://en.wikipedia.org/wiki/New_Zealand_English#Spelling
if the translation is the same for UK, AU and NZ then please
come." - Victor Hugo
>
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
From f9a2429f5b1049309623042e8519ee438cd40ce3 Mon Sep 17 00:00:00 2001
From: Steven Edwards
Date: Mon, 28 Dec 2009
Hi Dmitry,
On Thu, Dec 24, 2009 at 2:21 AM, Dmitry Timoshkov
wrote:
> Avoiding a needless renaming of ID_EXECUTE to ID_RUN would make the patch
> much smaller. Also avoiding useless typedef, making WineFile_OnRun() static,
> using correct casts, avoiding hungarian notation and magic flags would m
"Steven Edwards" wrote:
- Removed the LoadLibrary calls in favor of GetModuleHandle as suggested
by Paul Vriens
- Match the bad formating of the rest of the file
Avoiding a needless renaming of ID_EXECUTE to ID_RUN would make the patch
much smaller. Also avoiding useless typedef, making WineF
On Wed, Dec 23, 2009 at 1:26 PM, Paul Vriens wrote:
> Isn't shell32 already available (it's imported, see Makefile.in)? If so a
> GetModuleHandleW() would suffice.
Your right. Looking closer it looks like I didn't follow the Tab abuse
that's used in the rest of the file either so I'll resubmit wi
On 12/23/2009 07:08 PM, Steven Edwards wrote:
+hShell32 = LoadLibraryW(wszShell32);
Isn't shell32 already available (it's imported, see Makefile.in)? If so
a GetModuleHandleW() would suffice.
--
Cheers,
Paul.
orry - I could not yet verify it - please mail back it there other
issues.
Regards,
Martin
Am 17.07.2008 um 19:26 schrieb Dan Kegel:
> While valgrinding Picasa, I came across the following valgrind error
> in winefile. (My daily valgrind runs only run the conformance
> suite,
> While valgrinding Picasa, I came across the following valgrind error
> in winefile. (My daily valgrind runs only run the conformance
> suite, which is why I've never seen this before.)
> The lines involved seem unchanged since Martin Fuchs'
> winefile code was merge
While valgrinding Picasa, I came across the following valgrind error
in winefile. (My daily valgrind runs only run the conformance
suite, which is why I've never seen this before.)
The lines involved seem unchanged since Martin Fuchs'
winefile code was merged back in 2002.
Condition
l default) you'll see that most of
windows explorer actually lives there and not enough of the shell
namespace and friends is actually implemented. Thats partly another
reason I suggested using Program Manager and Winefile. For examples
see below. I know linking to ReactOS code is normally not
Austin English wrote:
> On Fri, Mar 28, 2008 at 3:40 PM, Juan Lang <[EMAIL PROTECTED]> wrote:
>
>>> Hasn't someone else somewhere in the world already written an explorer
>>>
>> > replacement and we could just get them to open source it so we can
>> > include it with Wine? No need to
Hey Juan!
On Fri, Mar 28, 2008 at 4:18 PM, Juan Lang <[EMAIL PROTECTED]> wrote:
> Personally, I think enhancing explorer to have its own GUI (rather
> than launching winefile) would be an interesting project. If nothing
> else, having a graphical way to explore the shell nam
>
> http://www.google.com/search?q=windows+explorer+replacement&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
Um.. yeah, I've heard of google, thanks. How many are written in ANSI C?
Find me one of those, and I'll retract my suggestion as a SoC project.
My suggestion
On Fri, Mar 28, 2008 at 3:40 PM, Juan Lang <[EMAIL PROTECTED]> wrote:
> > Hasn't someone else somewhere in the world already written an explorer
> > replacement and we could just get them to open source it so we can
> > include it with Wine? No need to reinvent the wheel.
>
> There's the Reac
> Hasn't someone else somewhere in the world already written an explorer
> replacement and we could just get them to open source it so we can
> include it with Wine? No need to reinvent the wheel.
There's the ReactOS one, but it's written in C++. I don't know of any
ANSI C ones, but maybe I ha
time to time the discussion comes up about having some sort of
> > Window manager or explorer replacement for when running in Desktop
> > mode.
>
> Personally, I think enhancing explorer to have its own GUI (rather
> than launching winefile) would be an interesting
> From time to time the discussion comes up about having some sort of
> Window manager or explorer replacement for when running in Desktop
> mode.
Personally, I think enhancing explorer to have its own GUI (rather
than launching winefile) would be an interesting project. If not
ories in the start menu to use
those as programs and program groups. Winefile could also use some
loving as well and maybe we could come up with a better way to tie it
in to the Program Manager. It seems to me that enhancing both of these
programs should take a few months or work and fill out a SoC
"Ivan Sinitsin" <[EMAIL PROTECTED]> wrote:
Changelog:
this patch add opportunity to save font option to the regestry, and load font
option from regestry in the winefile program
Nothing prevents you from writing and reading the whole LOGFONT structure
in one go.
--
Dmitry.
Ivan Sinitsin wrote:
> this is corrected patch for winefile.
You want to use the explicit RegQueryValueExW and RegSetValueExW functions.
bye
michael
>
> This patch adds an opportunity to keep adjustments of a font between
> sessions,
> if menu "Save settings
Hello Martin,
Martin Fuchs wrote:
> may I ask why you are replacing the simple malloc/free calls
> by the more complicated HeapAlloc API? This just makes
> the source longer and less readable. There is no point in avoiding
> C library usage in Winefile. It is just a unix application
Hello,
may I ask why you are replacing the simple malloc/free calls
by the more complicated HeapAlloc API? This just makes
the source longer and less readable. There is no point in avoiding
C library usage in Winefile. It is just a unix application using
Wine libraries - not a Wine system
On Di, 2007-06-26 at 13:00 +0200, Alexandre Julliard wrote:
> > splitpath.c appeared with the
> > initial import of the winefile source code.
>
> Winefile cannot import msvcrt because it has support for accessing
> Unix files too.
What about dynamic loading?
hdll = Lo
might have been usefull. splitpath.c appeared with the
> initial import of the winefile source code.
Winefile cannot import msvcrt because it has support for accessing
Unix files too.
--
Alexandre Julliard
[EMAIL PROTECTED]
"Ivan Sinitsin" <[EMAIL PROTECTED]> wrote:
+ static const WCHAR sFont[] = {'M','i','c','r','o','s','o','f','t','
','S','a','n','s',' ','S','e','r','i','f','\0'};
+ HDC hdc = GetDC(0);
...
+if( RegQueryValueEx( hKey, reg_font_facename, NULL, &type,
+ (LPBYTE
On Mon, Apr 09, 2007 at 05:26:22AM +0200, RusH wrote:
> Winefile seems to be hardcoded when it comes to opening folders. No
> matter what I do it always pops up. I tried deleting
> HKEY_CLASSES_ROOT\Folder and nothing changed.
How do you test this? For me using start on directories giv
Repost from wine-users(no answer there).
Winefile seems to be hardcoded when it comes to opening folders. No
matter what I do it always pops up. I tried deleting
HKEY_CLASSES_ROOT\Folder and nothing changed.
What can I do to convince wine to open folders with /usr/bin/nautilus
? I allready made
Robert Shearman wrote:
Using the following example:
#define ComboBox_AddString(hwndCtl, lpsz) \
((int)SendMessage((hwndCtl), CB_ADDSTRING, 0L,
(LPARAM)(LPCTSTR)(lpsz)))
In Wine source, UNICODE is not defined. So should the above be using
SendMessageW/LPCWSTR or SendMessageA/LPCSTR
Mike McCormack wrote:
Robert Shearman wrote:
Despite containing some useful macros, those macros are somewhat
broken as they are ignorant of UNICODE, so cannot be "fixed" by simple
conversion to inline functions.
Unicode isn't a problem as "void *" could simply be used, but there are
other
Robert Shearman wrote:
Despite containing some useful macros, those macros are somewhat
broken as they are ignorant of UNICODE, so cannot be "fixed" by simple
conversion to inline functions.
Unicode isn't a problem as "void *" could simply be used, but there are
other compatibility reasons wh
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 so - it provides a bunch of very usefull type safe
> >> macro definitions.
> >> (Sel
Mike McCormack wrote:
>
> Martin Fuchs wrote:
>
>> "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 y
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
Martin Fuchs wrote:
"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 p
;t be an integral part of
winefile, as it isn't winefile specific.
2. Should Find File be a stand-alone application?
3.What library should pack/unpack use? Should it use zip/unzip utilities or
some dll?
Thanks for answering any of these questions
Yours Truely,
Evgeny F
From: "Evgeny F" <[EMAIL PROTECTED]>
> Does anybody working on winefile right now?
Nobody seems to working on it Evgeny, I think you'd
be pretty safe to go ahead and do the work.
--
Dimi Paun <[EMAIL PROTECTED]>
Lattica, Inc.
Hi there!
Does anybody working on winefile right now? I would like to implement some
features, currently reported as unimplemented. (for example create directory
dialog)
If anybody is doing it right now, please contact to avoid duplicated efforts
Hi there!
Is anybody working on winefile right now?
I would like to implement some of its features currently marked as
unimplemented (like Create Directory).
So if anybody is working on it, please contact me in order to avoid
duplicating efforts.
Yours
Am Montag, den 20.02.2006, 12:57 -0500 schrieb Jason Green:
> > This patch adds the ability to save your window position to the
> > registry when using winefile.
> +static const WCHAR registry_key[] =
{ 'S','o','f','t','w','
On Tue, 2005-11-22 at 15:02 +0800, mengzhuo li wrote:
> ChangeLog:
> dlls/kernel/process.c
>
> limengzhuo [EMAIL PROTECTED]
>
> fix the error of double clicking chinese name txt file in software
> (e.g. winfile).
>
> it shows the error
> wine: cannot open builtin library for L"C:\\windo
Hi,
On Tue, Nov 22, 2005 at 03:02:16PM +0800, mengzhuo li wrote:
> ChangeLog:
> dlls/kernel/process.c
>
> limengzhuo [EMAIL PROTECTED]
>
> fix the error of double clicking chinese name txt file in software (e.g.
> winfile).
>
> it shows the error
> wine: cannot open
Craig macLeod wrote:
> I would like a change to the Winefile application to add the ability to
> parse the commandline for it. Mainly so you can pass in a startup folder.
>
> eg
> winefile c:/temp
>
> will open the selected path under /.wine/ folder.
Since this is also poss
Hi,
I would like a change to the
Winefile application to add the ability to parse the commandline for it. Mainly
so you can pass in a startup folder.
eg
winefile c:/temp
will open the selected path under /.wine/
folder.
This feature would be useful so an application can
open a
"Martin Fuchs" <[EMAIL PROTECTED]> wrote:
> Please be carefull to remove the code page pragmas.
> IMHO this is not the correct way.
> When there is no other code page given, the resource compiler uses the
> current code page of the operating system. And I don't think, all of those
> language speci
rc bug or a feature. We either need
> to remove '#pragma code_page' statements altogether, or add them
> to all included .rc files. I took the 1st approach.
> Changelog:
> Dmitry Timoshkov <[EMAIL PROTECTED]>
> Remove unnecessary #pragma code_page() statements
2005/8/19, Dmitry Timoshkov <[EMAIL PROTECTED]>:
> "Yuri Kozlov" <[EMAIL PROTECTED]> wrote:
>
> > Changelog:
> > fix for encoding Ru.rc
>
> > --- wine/programs/winefile/Ru.rc 2005-06-20 15:45:39.0 +0400
> > +++ bwine/prog
"Yuri Kozlov" <[EMAIL PROTECTED]> wrote:
> Changelog:
> fix for encoding Ru.rc
> --- wine/programs/winefile/Ru.rc 2005-06-20 15:45:39.0 +0400
> +++ bwine/programs/winefile/Ru.rc 2005-08-18 19:56:37.0 +0400
> @@ -20,6 +20,8 @@
>
> L
> > 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
ring character constants.
You are right, it is NOT allowed in Wine code since it's not portable
between compilers. There WCHAR[] is the right choice. However it is for
Winelib applications (at least the docs suggest it). As Winefile is on
one hand a Winelib application but on the other p
On Sun, 2005-07-03 at 13:31 +0200, Martin Fuchs wrote:
> 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
> > > 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.
On Sun, Jul 03, 2005 at 01:31:06PM +0200, Martin Fuchs wrote:
> > > 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
> > 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
> > So I see two solutions:
> > (1) make a hard break and change the whole winefile to Unicode. For
> > unixcalls.c you can rely on the Windows API for manipulating Unicode
>
> I can't find a replacement for wcsrchr() in the windows API, so I have to
> include my
ly.
>
> So I see two solutions:
> (1) make a hard break and change the whole winefile to Unicode. For
> unixcalls.c you can rely on the Windows API for manipulating Unicode
I can't find a replacement for wcsrchr() in the windows API, so I have to
include my own implementation in t
Hi Martin,
> 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
> or types, but inserting include/msvcrt in the include path
> conflicts w
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
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
> > no 16 bit file names to display.
>
>
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
> no 16 bit file names to display.
No, but using Unicode doesn't hurt, and is easier than going through
the effort of
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
> > 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 TCHAR, that doesn't mean you want to
> use it in new code. We have 16-bit support too but nobody
> advocates writing
API as possible.
>
> Wine obviously supports TCHAR, that doesn't mean you want to use it in
> new code. We have 16-bit support too but nobody advocates writing new
> 16-bit applications.
Winefile is not really "new code", it started back in the year 2000.
And as I pointed
"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 TCHAR, that doesn't mean you want to use it in
new code. We have 16-bit support too
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 it isn't constraint to
> being used in Wine
> only. For example it is currently also present
> > 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
that use , it doesn't necessarily say anything about the internal use
> of it or whether new applications should employ it.
Sure, is not designed to be used "internally" in Wine. But
the point is,
I would like to maintain Winefile such, that it isn't constraint to
being used in Wine
on
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
that use , it doesn't necessarily say anything about the internal use
of it or whether
Hi,
> 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 on
t; going pretty soon there will be more #ifdefs in winefile than in all
> the rest of the Wine codebase.
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
oes is
demonstrate why using TCHAR is a really bad idea. The way this is
going pretty soon there will be more #ifdefs in winefile than in all
the rest of the Wine codebase.
--
Alexandre Julliard
[EMAIL PROTECTED]
Changelog:
switch winefile to UNICODE mode
Why did I declare a new macro $(PREINCL) and insert it into Make.rule.in ?
To allow inserting the include directory before .
Another way would be to change the following line in Make.rule.in and move
$(EXTRAINCL) before -I$(TOPSRCDIR)/include
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
Martin Fuchs escreveu:
Changelog:
switch winefile to UNICODE mode
I don´t understand something or winefile can use Michael Jung´s unixfs
namespace extension?
+
+/* functions in unixcalls.c */
+
+extern void call_getcwd(char* buffer, size_t len);
+extern void* call_opendir(const char
> > 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
bui
"Martin Fuchs" <[EMAIL PROTECTED]> wrote:
> Changelog:
> switch winefile to UNICODE mode
Why to go through all this pain and not just make it unicode
only?
--
Dmitry.
On Sat, 2005-05-14 at 12:50 +0200, Jacek Caban wrote:
> Aren't we?
:) Of course, I just thought that maybe you were talking off the
list with other folks. Nevermind, I was half joking anyway.
--
Dimi Paun <[EMAIL PROTECTED]>
Lattica, Inc.
Dimi Paun wrote:
>On Fri, 2005-05-13 at 22:43 +0200, Jacek Caban wrote:
>
>
>>We're planning to add a new explorer application.
>>
>>
>
>Who's "we"?
>
>
>
Aren't we? I meant "we" as "wine developers", but maybe I should use
"you" as I didn't participate in the discussion. Anyway, as I re
On Fri, 2005-05-13 at 22:43 +0200, Jacek Caban wrote:
> We're planning to add a new explorer application.
Who's "we"?
--
Dimi Paun <[EMAIL PROTECTED]>
Lattica, Inc.
Hi.
Martin Fuchs wrote:
>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.
>
&
> > Doesn't HeapAlloc work on any 'Win32' platform?
>
> I want to avoid calling heap allocation functions.
> Using alloca() is slightly lighter.
Please don't do that. It uglifies the code, and makes
it less reliable. alloca() is lighter but it's on the
stack, and I really doubt that yoy can measu
> 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
On Fri, 13 May 2005, Martin Fuchs wrote:
Changelog
use macros for platform dependent temporary allocations
[...]
+#define TMP_ALLOC(s) HeapAlloc(GetProcessHeap(), 0, s)
+#define TMP_FREE(p) HeapFree(GetProcessHeap(), 0, p)
+#else
+#define TMP_ALLOC(s) alloca(s)
+#define TMP_FREE(p)
#endif
Why is th
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 se
Francois Gouget escreveu:
On Wed, 16 Feb 2005, Marcelo Duarte wrote:
[...]
+FONT 8, "Helv"
Is this correct?
I copied the English file and only translated the strings.
I thought that we were using "MS Shell Dlg" everywhere except for
Japanese where we use "MS UI Gothic" instead.
If this is the cor
On Wed, 16 Feb 2005, Marcelo Duarte wrote:
[...]
+FONT 8, "Helv"
Is this correct?
I thought that we were using "MS Shell Dlg" everywhere except for
Japanese where we use "MS UI Gothic" instead.
There does seem to be some inconsistencies. Two Japanese resource files
use "Ms Shell Dlg" instead of
Hi,
Alexandre Julliard escreveu:
ChangeSet ID: 16090
CVSROOT: /opt/cvs-commit
Module name: wine
Changes by: [EMAIL PROTECTED] 2005/02/14 05:12:30
In this file below, the correct is "usuário", but in cvs is incorrect
"usuário" and I dont know how to correct...
In my tree it is correct.
Index:
"Martin Fuchs" <[EMAIL PROTECTED]> writes:
> What happens if two mounted drives want to use different code pages?
> CP_UNIX is only one constant, and can't handle both cases.
> I suspect, there is some inherent problem with this approach.
No, Unix file names are interpreted according to the Unix
"Francois Gouget" <[EMAIL PROTECTED]> wrote:
> > What happens if two mounted drives want to use different code pages?
> > CP_UNIX is only one constant, and can't handle both cases.
> > I suspect, there is some inherent problem with this approach.
>
> I don't know the details but I'm told this is
1 - 100 of 127 matches
Mail list logo
