Marcus Meissner wrote:
> In Linux, L"" makes 4 byte character strings (if not using explicit
> -fshort-wchar). Also, if the user then calls wc* functions from glibc,
> they will use 4 byte characters.
>
> It is all to avoid confusion.
>
> Ciao, Marcus
Interestingly, it looks like, in one standar
Ravinder wrote:
I am currently working on making a windows program function in
wine. it works for the most part, so i'm trying to iron out a
few critical bugs. first off... i'm looking at microsoft's
CFileDialog class - it is what the standard windows 'open
file' and 'save file' dialog windows u
James Hawkins wrote:
To be as portable as possible, we code to the lowest common
denominator. Not all compilers support L"". We adhere to C89, but I
can't remember what it says about L"", if anything. The point is that
WCHAR blah[] ={...} will work for every compiler.
wchar_t is an int on s
On Thu, Jun 22, 2006 at 10:36:10PM +0100, Andrew Talbot wrote:
> James Hawkins wrote:
> > Probably, L"" is not portable, and you have to use:
> >
> > static const WHCAR string[] = {'s','t','r','i','n','g',0};
> >
> I'm just curious: not arguing, ;) but Plauger says, in "The Standard C
> Library"
James Hawkins wrote:
> To be as portable as possible, we code to the lowest common
> denominator. Not all compilers support L"". We adhere to C89, but I
> can't remember what it says about L"", if anything. The point is that
> WCHAR blah[] ={...} will work for every compiler.
>
>From what I ca
On 6/22/06, Vijay Kiran Kamuju <[EMAIL PROTECTED]> wrote:
Ok, no problem.
we can add delay import for advapi32. (guessing)
As most of the implemented functions use the same code, for
implementing those functions.
So I thought moving them to a common location would be a good idea.
Do you know wher
Ok, no problem.
we can add delay import for advapi32. (guessing)
As most of the implemented functions use the same code, for
implementing those functions.
So I thought moving them to a common location would be a good idea.
Do you know where should i move the common implementation to?
Thanks,
Vija
On 6/22/06, Vijay Kiran Kamuju <[EMAIL PROTECTED]> wrote:
Most of the dlls which have implemented the above functions
are importing advapi, because all/most of the Reg*Key functions are
implemented in advapi
I think this makes no difference to the existing dlls.
You misunderstood what I said.
On 6/22/06, Andrew Talbot <[EMAIL PROTECTED]> wrote:
James Hawkins wrote:
> Probably, L"" is not portable, and you have to use:
>
> static const WHCAR string[] = {'s','t','r','i','n','g',0};
>
I'm just curious: not arguing, ;) but Plauger says, in "The Standard C
Library" (1992, p. 219): "You wri
Most of the dlls which have implemented the above functions
are importing advapi, because all/most of the Reg*Key functions are
implemented in advapi
I think this makes no difference to the existing dlls.
Thanks,
Vijay
On 6/22/06, James Hawkins <[EMAIL PROTECTED]> wrote:
On 6/22/06, Vijay Kira
On 6/22/06, Vijay Kiran Kamuju <[EMAIL PROTECTED]> wrote:
Hi All,
I would like to move all the helper functions register_coclass,etc to
a separate file in advapi.dll called regsvr_helper.c and all
declarations of structs, consts moved to a separate file called,
wineregsvr.h in include/wine
So t
James Hawkins wrote:
> Probably, L"" is not portable, and you have to use:
>
> static const WHCAR string[] = {'s','t','r','i','n','g',0};
>
I'm just curious: not arguing, ;) but Plauger says, in "The Standard C
Library" (1992, p. 219): "You write a wide character constant as, for
example, L'x'. I
Hi All,
I would like to move all the helper functions register_coclass,etc to
a separate file in advapi.dll called regsvr_helper.c and all
declarations of structs, consts moved to a separate file called,
wineregsvr.h in include/wine
So that it would be easy for other dlls to implement the
DllReg
On 6/22/06, Dan Kegel <[EMAIL PROTECTED]> wrote:
I just looked, and there aren't *that* many msi and ole bugs
reported in bugzilla.
Would it be unreasonable to set a goal of having
all msi and ole bugs fixed for wine-1.0 ?
Just to clarify that last statement, you mean all reported msi and ole
On 6/22/06, Krzysztof Foltman <[EMAIL PROTECTED]> wrote:
This is the EM_GETLINE patch from Thomas Kho, updated to current git and
with L"" replaced by proper WCHAR array.
Krzysztof
==
Hi,
The following patch implements EM_GETLINE. This featu
I just looked, and there aren't *that* many msi and ole bugs
reported in bugzilla.
http://bugs.winehq.org/buglist.cgi?product=Wine&component=wine-ole&keywords_type=allwords&keywords=download&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
lists 37 ole bugs with downl
On 6/22/06, Krzysztof Foltman <[EMAIL PROTECTED]> wrote:
This patch seems to have been overlooked or rejected - yet I do not see
any reason being mentioned.
Was it rejected because of use of L"" syntax?
Probably, L"" is not portable, and you have to use:
static const WHCAR string[] = {'s','t
On 6/22/06, Piotr Caban <[EMAIL PROTECTED]> wrote:
Hi,
Changelog:
- Added CreateInstanceOn functionality
Make sure you label a series of patches as OleView [1/x] etc. where x
is the total number of patches, so if they are received out of order,
Alexandre knows what order to apply them in.
-
On 6/21/06, James Hawkins <[EMAIL PROTECTED]> wrote:
Hi,
This fixes bug 3590.
Changelog:
* Load all components, not just components associated with a feature.
Ignore this patch, it's not correct.
--
James Hawkins
Hi Christian Gmeiner:
> It seems that there
> is no SetupDiCreateDeviceInfoW exporteded by setupapi.dll on windows
SetupDiCreateDeviceInfoW is exported:
http://support.microsoft.com/dllhelp/?dlltype=file&l=55&S=1&alpha=setupapi.dll
Example Version:
http://support.microsoft.com/dllhelp/?fid=914
On 22/06/06, Krzysztof Foltman <[EMAIL PROTECTED]> wrote:
This patch apparently has been lost, and there's at least one bug inBugzilla that the patch seems to fix (bug# 4452, checked here).
http://www.winehq.org/pipermail/wine-patches/2006-January/023875.htmlI don't see anything wrong with the patc
Jonathan Clark wrote:
Judging by the two negative reactions
Based on the expressive smiley in my posting, I'd hardly consider it negative.
It was more of a well-meaning joke, but perhaps also one that told how
your posting could be interpreted.
I *would* find it interesting to know how much i
Hi,
Piotr Caban wrote:
Hi,
Changelog:
- Removed use of strlenW, strcmpW, strcpyW functions
programs/oleview/details.c | 14 +++---
programs/oleview/tree.c| 16
2 files changed, 15 insertions(+), 15 deletions(-)
--
Piotr
You should also remove include wi
On 6/21/06, Andrew Talbot <[EMAIL PROTECTED]> wrote:
Changelog:
oleview: Link with wine's unicode libarary.
We should be changing the strlenW to lstrlenW, not adding
$(LIBUNICODE) to the Makefile.
--
James Hawkins
24 matches
Mail list logo
