The way I see it, you decide on a FEATURE freeze. Then you cut the
stable branch. Next, you start stabilizing that branch for release, not
allowing commits into that branch of new features. Once it is released,
you merge the changes there into the development tree, and perform a new
feature
Hi list,
Like I mentioned ealier last week, I intend to add BiDi support to WINE.
There is a library called fribidi (http://fribidi.sourceforge.net/) that
does a pretty good job, and seems exactly apropriate for this task. I
have two questions:
A. What are my chances of getting a patch of
http://bugs.codeweavers.com/show_bug.cgi?id=519
Unicode defines a character known as BOM, that identifies a file as a
UNICODE encoded file. Though this file should probably not be printed,
if sent as the first char to DrawText or ExtTextOut windows ignores it.
Wine doesn't.
I'll probably
1. I tested a small UNICODE program I wrote that used DrawText, and it
printed Hebrew just fine on my system (Debian SID, don't know what
version of WINE). It didn't print Hebrew with the ANSI version, but that
is probably just a codepage problem, as ExtTextOutA simply converts the
string to
, 2002 09:51 am, Shachar Shemesh wrote:
A. What are my chances of getting a patch of this magnitude incorporated
into the tree. The library is not particularily big, but includes a set
of unicode translation files that are automatically generated from the
unicode standard. It seems that WINE holds
Huw D M Davies wrote:
Hi Shachar,
Assuming you're using client side rendered fonts then most of the font
support for Hebrew/Arabic/whatever should be in the tree, so that you
should be able to render any glyph with a Unicode point that exists in
the font (I'd like to konw of any problems you
Francois Gouget wrote:
Bug 98 - Unicode, i18n support is quite vague. How could I flesh it
out?
For instance I am thinking that we could convert this into a
metabug and have one sub bug for each control that still needs to
be unicodified. So:
* which are the common controls that still
Dmitry Timoshkov wrote:
One more thing that should be addressed IMO as the part of the unicode
support in Wine: file APIs. For instance in the current state all russian
file names created by windows programs are completely unreadable in Linux
because they are created in code page 1251 but
Dmitry Timoshkov wrote:
Filenames, created by windows programs running under Wine, of course are
seen correctly *under Wine*. But regular Linux applications for apparent
reasons display them incorrectly, but still can open them.
One more thing I don't understand is this. The filenames are a
Dmitry Timoshkov wrote:
Probably I didn't make my position clear enough and somehow you
misunderstood me and decided that I propose to use code page 20866
instead of 1251 for russian locale under Wine. But that's not the case.
I only proposed to create filenames on disk in encoding used
Geoffrey Hausheer wrote:
On Sunday 07 April 2002 20:29, you wrote:
Geoffrey Hausheer [EMAIL PROTECTED] wrote:
So is there a better solution than the three I've listed?
And why won't wine let me include 'windows.h', but under windows it is
required?
Probably it would be better to use Wine
One thing you may try are the explicit BiDi specifiers (Right to left,
left to right etc.). These are Unicode characters designed to explicitly
specify the direction of otherwise amigious characters.
Ansii does not have, to the best of my knowledge, an equivalent encoded
characters.
Ian Pilcher wrote:
leanne wrote:
We tried to print Chinese on notepad but failed.
We found that WINE default only writes western characters
to postscript. Is that true?
...
I would like to ask if WINE will support multi-byte character printing?
The PostScript driver
Are you sure it wouldn't make more sense to implement a NULL midi device
in Linux?
Shachar
Chris wrote:
i'd like to contribute to the wine codebase and for some applications of
mine they request i have a midi device, but since i don't have one in
linux, wine doesn't show one
Hi all,
I am using Debian SID with KDE. In KDE, I defined two keyboard layouts
(US and IL). I tried to add Israeli keyboard detection using the
attached patch (layout.diff). When trying to test that patch, however, I
perform the following task:
I type in the command as suggested in the docs
Timoshkov wrote:
Shachar Shemesh [EMAIL PROTECTED] wrote:
I am using Debian SID with KDE. In KDE, I defined two keyboard layouts
(US and IL).
Please provide them for reference. I would suggest create new keyboard
layouts using existing tables at /etc/X11/xkb/symbols/ though.
Ok, here
Patrik Stridvall wrote:
I have read through the diff (rather quickly) and it seem to be OK.
In fact I can't think of anything in the C semantics that can make a
difference if trailing whitespace or extra semicolon is removed.
petty asshole response
I can.
printf(blah blah blah \_
);
Remove
Shachar Shemesh wrote:
Hi all,
I am using Debian SID with KDE. In KDE, I defined two keyboard layouts
(US and IL). I tried to add Israeli keyboard detection using the
attached patch (layout.diff). When trying to test that patch, however, I
perform the following task:
I type
Dmitry Timoshkov wrote:
Shachar Shemesh [EMAIL PROTECTED] wrote:
The problem is that the Hebrew keysyms are at 0x0fe0-0x0ff9.
According to keysymdef.h Hebrew keysyms are in the range 0xcdf - 0xcfa
What says xev when you type hebrew characters?
xev agrees with keysymdef.h. Strange
Hetz Ben Hamo wrote:
Hi all,
Further research revealed the problem, and here is a working patch. I
would like to both draw your attention to the reasons, and point out one
thing in this patch that requires attention.
And I tried your patch Shachar and there some interesting results...
Michael Cardenas wrote:
On Thu, May 23, 2002 at 01:28:38AM +0100, Michael Wetherell wrote:
On Wednesday 22 May 2002 10:39 am, Tijs van Bakel wrote:
Either I could work on winedbg to match
gdb's features, or I could try to make gdb understand Wine better.
Given the amount of useful
Nerijus Baliunas wrote:
On Sat, 01 Jun 2002 14:30:36 +0300 Shachar Shemesh [EMAIL PROTECTED]
wrote:
I believe the problems you are experiencing have nothing to do with the
keyboard layout problem, but with the keyboard switching detection.
Does it mean it should work if I change
It's been a while since I looked at the compilation options of the
kernel, but there used to be specific support for java applets in the
kernel (running a userland jvm, mind you). That was later deprecated by
a MISC handler, that (I guess) could be configured to run java, and
probably also
Hi.
I tried repeating Hetz's experiment, and run the command LANG=he_IL
wine notepad, and then type a few (random) Hebrew chars. I get the
following messages on screen:
Warning: Language 'he_IL' was not found, retrying without country name...
fixme:edit:EDIT_EM_FmtLines soft break enabled,
Dmitry Timoshkov wrote:
Shachar Shemesh [EMAIL PROTECTED] wrote:
I tried repeating Hetz's experiment, and run the command LANG=he_IL
wine notepad, and then type a few (random) Hebrew chars. I get the
following messages on screen:
Warning: Language 'he_IL' was not found, retrying without
Dmitry Timoshkov wrote:
What reports xev? (And it would be a good idea to add setlocale(LC_CTYPE,);
at the very first lines of xev.c, recompile it, and check whether it still
works).
I did not setlocale as you suggested, but I did not set LANG= anything
when running it either. My
FYI.
---BeginMessage---
Bugzilla Security Advisory
Jun 8th, 2002
All Bugzilla installations are advised to upgrade to the latest versions
of Bugzilla released today, 2.14.2 and 2.16rc2.
Various security issues of varying importance have been fixed in
Bugzilla 2.14.2. Most of these were
wrote:
Shachar Shemesh [EMAIL PROTECTED] wrote:
I typed a Hebrew word, followed by a english one (you can also see the
keys used to tell kxdb to switch keyboard layouts). I am guessing that X
needs some global config to make Hebrew work, but I don't know what or
where it is. Maybe I need to set
Dmitry Timoshkov wrote:
Shachar Shemesh [EMAIL PROTECTED] wrote:
Ok, I found the problem with the kind help of the Ivrix mailing list guys.
The problem was that the locales were not installed (none of them). I
installed the locales and presto - everything started to work. Thanks
I am not sure about the specific case, but I do have some experience
with handling DBCS in general.
When using TCHAR and defining MBCS (which is the default with VCC - MS
doing something nice for a change) the result (if my memory serves me
correctly) is an unsigned char. This means that it
Paul Millar wrote:
BTW, has MS taken down their API reference from the MSDN website? I was
looking for the Win32 API reference on the MSDN web-site (to try and fix
the regression tests), but I couldn't find them. As far as I can remember,
it was available from MSDN Home -- MSDN Library --
Hi all,
I found that using the default ./configure options, the Makefiles are
generated with -g -O2 compilation options. This combination doesn't
make sense to me, as what use are debug options if I cannot trace
execution in a debugger.
My autoconfig knowledge is not deep enough to
Not as nasty as when you find out that when you use CString, the same
thing happens there. The MSDN used to say something along the lines of
CString fully supports MBCS, with a footnote stating that all the
problems that happen when you work with strings still happen, and you
take care of
Attached is an extremely preliminary BiDi patch. Here are the things
this patch contains, and the points I would love to hear the list's
comments about. This patch is under the LGPL only, at this stage.
Changes:
* Fixed the heb.nls file so that LANG=he_IL will be accepted
*
I think the correct thing to do is return the output of *_tcslen*. Since
we don't have TCHARs inside wine, this translates to using wcslen if
wer'e a UNICODE function, or strlen if wer'e not (notice that while
_mbslen returns the number of characters in the string, strlen returns
the number
Andriy Palamarchuk wrote:
Sachar, this is a great explanation, but as I
understand the processing you mentioned should be done
in the controls (e.g. edit field) window procedures.
Can you submit a bug for this? You can give better
information than I and add dependencies on othe bugs
about
Andriy Palamarchuk wrote:
Can you submit a bug for this? You can give better
information than I and add dependencies on othe bugs
about MBCS, BiDi, etc. (I guess this bug will be
assigned to you as the component owner ;-)
Can you also make it depend on bug 791?
Submitted
Hi all,
I am trying to find any references to the old unicode standard. In
particular, I need the Bidirectional algorythm used with ~unicode 1.0.
If anyone can help, it would be greatly apretiated.
If you don't have the 1.0 standard, but do have a later standard (but
not 3.0, which is what
Alexandre Julliard wrote:
Andriy Palamarchuk [EMAIL PROTECTED] writes:
On my comments Alexandre said that this is how it is
supposed to work:
http://www.winehq.com/hypermail/wine-devel/2002/06/0242.html
Alexandre, so this will work correctly or after your
yesterday's patch it won't affect
Andreas Mohr wrote:
Hmm, which approximate time frame is this ?
1998 ? 94 ? 89 ? :-)
I'm talking about the 1991-2 time frame. I believe this makes it
~Unicode 1.0. A later version could come in handy as well. See later on.
[EMAIL PROTECTED] wrote:
Shachar,
I have the version 1.0 and
Hi WINE-devel list (cross posted to Linux-IL),
After a lively discussion in the Israeli Linux users mailing list, it
appears that the best solution will be to give a command line (or
config) option to use an external library (fribidi) for the RTL
rendering. I would still implement this
Hi list,
Returning after a short absence, I have bug 864 to discuss (I have
opened it, and will soon be closing it).
The problem was that a program I wrote used ChooseFont with a
resource. I know those are not supported, but when compiled for Unicode
(in VC), the program crashed when trying
WOW, if wine is advanced enough to catch and spread outlook bugs, we
must be really moving along.
Seriously, though. If anyone here knows friest, and corresponded with
him on the subject of DOSEMU team, and is using Windows, please check
your system. You are infected with a variant of the
+ LPWSTR lpText = (LPWSTR)lParam;
+ lpText[0] = '\0';
Shouldn't it be
+ LPWSTR lpText = (LPWSTR)lParam;
+ lpText[0] = L'\0';
?
Carl Sopchak wrote:
I found this while trying to get Quicken 2000 Deluxe to run under wine. Q2k
was crashing when adding a new
Francois Gouget wrote:
On Mon, 15 Jul 2002, Shachar Shemesh wrote:
+LPWSTR lpText = (LPWSTR)lParam;
+lpText[0] = '\0';
Shouldn't it be
+LPWSTR lpText = (LPWSTR)lParam;
+lpText[0] = L'\0';
It does not matter. Both are equivalent
Ok. At least have a small util to convert a string to this format.
Sh.
Francois Gouget wrote:
On Wed, 17 Jul 2002, Dmitry Timoshkov wrote:
Francois Gouget [EMAIL PROTECTED] wrote:
'H','e','n','c','e',' ','t','h','e',' ','t','e','r','m',' ',
Francois Gouget wrote:
So to have a clean configure, the above header must be moved out of the
big AC_CHECK_HEADERS and into their individual checks where we can
specifically test for these dependencies. See for instance XShm.h (only
a vague quide).
I'll try, but I only have solaris
Personally, I do:
if( condition)
some meaningless nop;
And then set or clear the breakpoint on the nop if I want. This gives me
debug time control over the breakpoint without giving up on the flexability.
Shachar
David Hammerton wrote:
You could do a raise(SIGSTOP),
Jeremy Newman wrote:
I talked to Alexandre, the tree is up to date as far as we call tell.
Can you check again?
Anyone else seeing anything missing in CVS?
On Tue, 2002-08-13 at 11:11, Andreas Mohr wrote:
On Tue, Aug 13, 2002 at 11:59:28AM +0200, Sylvain Petreolle wrote:
I checked
Jeremy Newman wrote:
I see what's going on now. There must have been a local cvsup running
when the server crashed. It left a lock file in place. I deleted that
lock file and restarted cvsupd. The public cvs tree is now in sync with
the commit tree.
On Tue, 2002-08-13 at 12:24, Shachar Shemesh
Hi all,
A patch just submitted to wine-patches changes the rules when building
binary packages of WINE for distributions. This is an optional change,
so ignoring this email will not break anything, but will result in
decreased functionality.
During the configure phase ./configure will now
Dimitrie O. Paun wrote:
On August 15, 2002 12:08 pm, Shachar Shemesh wrote:
configure.ac:
Added a check for the existance of the fribidi include file. No
check for the library, as we do not statically link with it.
Like any programmer, I usually hate copying stuff around
Lionel Ulmer wrote:
X Error of failed request: XF86DGANoDirectVideoMode
Major opcode of failed request: 136 (XFree86-DGA)
Minor opcode of failed request: 22 (XDGAOpenFramebuffer)
Serial number of failed request: 181
Current serial number in output stream: 181
NOTE - What does this
Alexandre Julliard wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
If the general public here votes to remove the ac related code, I'll
go along with it (no question about it making my code simpler, albeit
marginally).
I suggest you write the real code first, and let us worry about
I did the following:
make dist-clean
CFLAGS=-g ./configure
make depend
make
For some strange reason, I get the following errors:
make[2]: Entering directory `/home/sun/sources/wine/wine/programs/winhelp'
gcc -o hlp2sgml hlp2sgml.o hlpfile.o
hlpfile.o: In function `HLPFILE_ReadHlpFile':
+/*
+ * The main BiDirectional functions, and interface to FriBiDi
+ *
+ * Copyright 2002 Shachar Shemesh.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation
Alexandre Julliard wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
No actual patch, yet, as I still have a few heap corruptions in
certain cases. Attached, however, is the preliminary Wine with
external libfribidi. Do your worst, come back with an opinion. This
is not, yet, cleaned up
Alexandre Julliard wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
3. Things are further complicated by the fact that it has no out of
bounds way of specifying what the base direction is (and, MS being
MS, this means that a base direction of LTR is chosen
Alexandre Julliard wrote:
What I'm saying is that it's not a good idea to start using fribidi,
create dependencies and problems for packagers, etc. if we know that
it's a wrong design and that we will need to replace it.
Ok, accepted. Not only by me, but also by Bidi's maintainers.
I'm
BiDi - 5% done.
me
tom wrote:
Hello ,
The Wine Status page located here :
http://www.winehq.com/about/index.php?status
Has gone for about one year now with out updates and I
have volunteer'd to work on bringing this page up to date.
I am new to the Wine Project and I am in need of some
Eric Pouech wrote:
my point is:
- a company X has an audio player for Win32
- company X ports its app to Wine using the wine source, and it's mp3
player and makes a closed package of it
- it'll have to pay for the license
so I think this has to be documented somehow
A+
Isn't it always the
Marcus Meissner wrote:
Such a thing is not really implemented yet.
Does anyone have any objections to me having a go at implementing it
(perhaps at some time in the future)?
There is a freeware tool called 'valgrind' which might be instrumentable,
but I do not think it can cope with wines
Francois Gouget wrote:
All I'm saying
is that since they match the Microsoft values they are by definition
correct.
I think correct is too strong a word here. I would go for conforming.
Shachar
Dimitrie O. Paun wrote:
Now, talking about 100% complete, we should define a little
better what we mean by this percentage. I suggest that it
estimates the completeness of *documented* features,
since the undocumented ones are simply gagable. This being
said, a component reaches 100% complete
Dimitrie O. Paun wrote:
I don't understand then on what you disagree, even slightly. All I said
is that we should gage the *documented* features, not the undocumented
now. The percetages 100 are a gut feeling anyway, no point in making
to stringent rules about them. That being said, I agree
Dimitrie O. Paun wrote:
On September 6, 2002 05:16 pm, Lionel Ulmer wrote:
As of lately, this no longer happens: I get a big fat conflic for all
the changes I submit! This is *very* annoying. Anyone knows
how to fix this behaviour? Alexandre, are you doing anything
different?
Maybe
Andriy Palamarchuk wrote:
Unicode is supported relatively well in Wine. Please
report if you have any issues with it.
Andriy
Except where special manipulations are required (reordering, ligation,
diacritics etc.). How are we on Kerning, BTW?
Shachar
Hi,
Would it be possible to tag each release announced to wine-announce in
the CVS, so cvs co -r WINE_20020702 wine will actually get the wine
version that corresponds to that release?
I know I can do cvs co -D 2002-jul-02 wine for similar effect, but I
don't like that solution. It has not
For me the problem happened when I used the grsecurity patch for 2.4. It
appears that, in an attempt to block some exploits, the patch will use
that address for glibc, thus making it unavailable for normal load
(quoting Alexander's reply to my query). This should not, normally, pose
a
I don't get it either.
Synch the current WINE CVS on sourceforge with the winehq one. Create a
branch on the SF CVS. Every so often, create a hook that will commit
changes to the main WINEHQ cvs to the main SF CVS (or create an
automatic hook reading from wine-cvs).
Every so often, someone
Dmitry Timoshkov wrote:
Here are (once more) items I had sent you earlier:
1. Add support for Hebrew and Arabic: worker Shachar Shemesh.
Actually, he had that one under BiDi support.
2. Add support for more keyboard layouts to x11drv.
3. Figure out what should be done for better support
Who is maintaining our Bugzilla system?
Shachar
---BeginMessage---
Bugzilla Security Advisory
October 1st, 2002
All Bugzilla installations are advised to upgrade to the latest versions of
Bugzilla, 2.14.4 and 2.16.1, both released today. Security issues of
varying importance
You see dutch because the english locales in many of our apps are marked
as sublanguage NEUTRAL instead of DEFAULT.
This causes a problem when your locale is not matched by any of the
resources. Usually, English is picked as a fallback, but since the
english resource is incorrectly defined,
I've had a similar problem. X uses the current locale in order to
convert the keycode into a character. Try setting you language type to
Hungarian and then report. If you don't want to set the system locale,
try the following command (under bash):
LANG=hu wine ...
This will set the
I think Wine should, and CAN, do without privelege escalation at all.
Let's look at some of the examples presented here. If we want to give a
multi user Windows experience that is compatible with the multi-user
Unix experience, our trust model must be comperable. My view of such a
case is
Dustin Navea wrote:
--- Steve Langasek [EMAIL PROTECTED] wrote:
On Thu, Oct 24, 2002 at 08:08:49AM -0700, Dustin
Navea wrote:
or what if someone just changes the
owner/group on the file (like a word doc), and
then
tries to run it with wine, what happens then?
make[2]: Entering directory `/home/sun/sources/wine/wine/dlls/d3d8'
../../tools/makedep -I. -I. -I../../include -I../../include
-I/usr/X11R6/include -C. basetexture.c cubetexture.c d3d8_main.c
device.c directx.c indexbuffer.c resource.c surface.c swapchain.c
texture.c vertexbuffer.c volume.c
Rizsanyi Zsolt wrote:
On Saturday 12 October 2002 22:58, Shachar Shemesh wrote:
make[2]: Entering directory `/home/sun/sources/wine/wine/dlls/d3d8'
../../tools/makedep -I. -I. -I../../include -I../../include
-I/usr/X11R6/include -C. basetexture.c cubetexture.c d3d8_main.c
device.c directx.c
Excuse me, but I don't think that any of these proposed methods will
live up to any real malicious code. Personally, I believe we should make
wine:
A. Not require root
B. As secure on it's own as possible (i.e. - not open to any problems
not introduced by the hosted program).
These two should
Oh my god!!! he is running out of alphabet letters!!! ;-)
Shachar
Dimitrie O. Paun wrote:
ChangeLog
Mark immutable objects as const. Fix inconsisten *-style.
--- dlls/comctl32/listview.c.Z6 2002-10-27 10:29:52.0 -0500
+++ dlls/comctl32/listview.c 2002-10-27
what version that was), then the first character, א, is
on the *right* `-)
Shachar
Dimitrie O. Paun wrote:
On October 27, 2002 12:14 pm, Shachar Shemesh wrote:
אבגדהוזחטיכלמנסעפצקרשת. Very useful `-)
Very cool man, but, ..., hmm, ..., I don't have a Hebrew keyboard. ;)
alephbet,
would he have to change from Z1, Z2,... to 1{aleph}, 2{aleph},...
-- Jeff S.
From: Shachar Shemesh [EMAIL PROTECTED]
That's why I included them here, so you can copy and paste
Just remeber to set your locale to either Iso-8859-8 or UTF-8, or
you'll lose the special chars. Even
Vincent Béron wrote:
Le mar 29/10/2002 à 05:12, Juraj Hercek a écrit :
Hi,
Hi,
Next, current snapshot from cvs doesn't compile on solaris, is anyone
compiling wine on solaris?
Recently, I know Shachar has contributed patches for compiling on
Solaris, but I don't know the current state
Jaco Greeff wrote:
On Tue, 29 Oct 2002 21:10:52 +0100, Andreas Mohr
[EMAIL PROTECTED] wrote :
[insert some rant about certain highly non-rewarding functions here...]
Still, you're doing some pretty essential work, so let me just say thanks
for your (annoying ?) work !
Annoying?
Ender wrote:
- Getting the right set of dlloverrides and registry entries correct
for a large portion of software is irritating. Most of this comes down to
the lack of WINE being able to dynamically run RunOnce and wininit.ini
entries. Doing this manually is far beyond your average user
Andreas Mohr wrote:
On Wed, Oct 30, 2002 at 12:21:51PM +0200, Shachar Shemesh wrote:
Ender wrote:
- Getting the right set of dlloverrides and registry entries correct
for a large portion of software is irritating. Most of this comes down to
the lack of WINE being able to dynamically
Johan Gill wrote:
Even with perfectly working builtin dlls, one needs overrides for the
native dlls that are proprietary, or the loading will fail. Or is this a
bug?
/Johan Gill, [EMAIL PROTECTED]
The way I see it, no windows installs of wine should have dll load order
set to native,
So you mean to say that my windows X-Eyes implementation won't work on
WINE? Damn.
Anyone knows of any Unix port of that program?
Shachar
No, wait. I'm using a mouse hook. Maybe it'll work after all.
Sh.
Alexandre Julliard wrote:
[EMAIL PROTECTED] writes:
Johan Gill wrote:
On Thu, 31 Oct 2002, Shachar Shemesh wrote:
The way I see it, no windows installs of wine should have dll load order
set to native, builtin for all DLLs.
I'm not sure that we are talking about the same thing here...
Just to be safe, what I mean is that if I want to run
it to the list) at
http://www.consumer.org.il/personal/xeyes.zip.
D/L size is 49Kb.
Thanks,
Shachar
Alexandre Julliard wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
So you mean to say that my windows X-Eyes implementation won't work on
WINE? Damn.
Anyone knows of any Unix
Mark Hannessen wrote:
On Friday 01 November 2002 21:29, you wrote:
On November 1, 2002 01:07 pm, Mark Hannessen wrote:
most games i own install and run ferfectly, but will not give you
out the box experience because wine lacks good copy protection code.
Diablo II is a good example
Can't
What about reboot.so or similar support? Andreas said he was deffering
sending in an official patch. I was willing to take ownership over that
(whether from scratch, or based on work done so far) is Andreas isn't
interested any more.
Shachar
Dimitrie O. Paun wrote:
This will
Mark Hannessen wrote:
Game-wise:
Jazz Jackrabbit 2
Fallout
Neverwinter Nights
Grand Prix Legends
Discworld II
Did you???
Displays three logos, shows the copyright screen (with death on a
horse), starts playing the music and goes into a loop. What did you do
to get it
Zsolt Rizsanyi wrote:
On Sunday 03 November 2002 02:26, Dustin Navea wrote:
--- Adam Ernst [EMAIL PROTECTED] wrote:
I'm sorry if this is off topic or doesn't belong here. I'm not a
developer (at least not in C) so I'll wait a few years while I learn C
before I come back and help you
Gavriel State wrote:
Mark Hannessen wrote:
When the patch was published, there was a discussion, and the
conclusion was that the code is very probably legal, and is not
against DMCA
Are you sure about the above statements? Have you checked that, or
it is just your opinion?
Carlos words
One more bug:
FIXME still reports the CF_ENABLETEMPLATE flag as non-supported.
Shachar Shemesh wrote:
ChangeLog:
Shachar Shemesh [EMAIL PROTECTED]
Todo:
* Implement support for the scripts selection.
o Enum the scripts the font supports, and display the list
accordingly
Hi,
I was going over the notepad code, and it is implemented using richedit.
My question is - why? There is no functionality there that is not also
available through the usual Edit control. The Windows notepad is
notoriously implemented via the edit control. Is there a special reason
why our
wrote:
Shachar Shemesh [EMAIL PROTECTED] wrote:
I was going over the notepad code, and it is implemented using richedit.
My question is - why? There is no functionality there that is not also
available through the usual Edit control. The Windows notepad is
notoriously implemented via the edit
Dmitry Timoshkov wrote:
Shachar Shemesh [EMAIL PROTECTED] wrote:
I was going over the notepad code, and it is implemented using richedit.
My question is - why? There is no functionality there that is not also
available through the usual Edit control. The Windows notepad is
notoriously
Dmitry Timoshkov wrote:
Shachar Shemesh [EMAIL PROTECTED] wrote:
I'm trying to revamp notepad a little. In particular, I'm trying to add
the select font option to it. This is problematic under the RICHEDIT
control, as each character there can, potentially, have it's own font
1 - 100 of 265 matches
Mail list logo
