Sunday, October 19, 2003, 10:12:06 PM, you wrote:
> On October 19, 2003 07:41 pm, Vitaliy Margolen wrote:
>> Not true. Native uses default tab size of 96.
>>
>> - The minimum size of a tab is at least icon width + 3 if icon is present.
>>
>> - Prior observation that "under Windows, there seems
On October 19, 2003 01:05 pm, Ferenc Wagner wrote:
> But here is the reason: I was sure fgets was deprecated.
> For whole bunch of libc input functions this is for possible
> buffer overruns, but not for fgets. The problem here is
> that you can not tell a NUL in the input stream.
Yes, I know, I
On October 19, 2003 07:41 pm, Vitaliy Margolen wrote:
> Not true. Native uses default tab size of 96.
>
> - The minimum size of a tab is at least icon width + 3 if icon is present.
>
> - Prior observation that "under Windows, there seems to be a minimum width
> of 2x the height for button style t
Title: RE: WWN: wn20031017_192.xml
> Test these lines
> BEGIN { FS = "\"" }
> { A+=$2 }
> { B+=$4 }
> END { print "
> who=\""$6"\" />" }
Works like a charm! Thanks!
---
Brian Vincent
Copper Mountain Telecom
[EMAIL PROTECTED]
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
> I am trying to make an application work under wine. The app is probably
> an MFC app, that defenitely uses MDI. The problem boils down to this -
> it tries to create an MDI window by doing SendMessageA to a message of
> type "WM_MDICREATE". Here's
On Sun, 19 Oct 2003 23:23:44 +0200
"Ivan Leo Murray-Smith" <[EMAIL PROTECTED]> wrote:
> >Is it a patent for a hrdware solution, or for software? If software then in
> >Europe, at least in Germany and others, it wouldn't matter because
> >softwarepatents are not possible (and hopefully never will).
On Mon, 20 Oct 2003 00:20:29 +0200, "Ivan Leo Murray-Smith" <[EMAIL PROTECTED]>
wrote:
>No, if you're in the US and publish something in the EU, you aren't violating
>any US law, as you aren't publising anything in the US. If this isn't the case,
I'm not hundred percent sure. If you are in the US
This fixes another problem on my automatic tester's radar.
The only user of this array is commented/disabled, so I suggest to
either move the array or completely yank it.
Gerald
ChangeLog:
Move event_names[] into EVENT_ProcessEvent().
Index: wineclipsrv.c
On Sunday 19 October 2003 05:20 am, Mike Hearn wrote:
> On Sun, 19 Oct 2003 01:00:51 -0500, Sir Gregory M. Turner scribed thus:
> > which ostensibly would seem to contradict your prognosis... (although I
> > assume you are nevertheless correct -- this is not the root-dir
> > configure, so maybe it'
>But what would that mean for the developers in the US? Just because the
>sources are hosted in EU would still render them useless for US developers.
No, if you're in the US and publish something in the EU, you aren't violating
any US law, as you aren't publising anything in the US. If this isn't t
On Sun, 19 Oct 2003 23:23:44 +0200, "Ivan Leo Murray-Smith" <[EMAIL PROTECTED]>
wrote:
>Also, this thread should be on wine-license.
Sorry, but I haven't subscribed to it. I hope this is acceptable. If not I
stop posting here in this thread.
>It wouldn't be hard to host wine in the EU, codeweave
--- "Gregory M. Turner" <[EMAIL PROTECTED]> wrote:
> Hmm, now that I think about it, for full compatibility with winelib,
> maybe we
> require something like:
>
> typedef stuct ... { ... } CABINET_INFO_W, CABINET_INFOW;
> typedef struct ... { ... } CABINET_INFO_A, CABINET_INFOA;
> DECL_WINELIB_TY
This is really the heart of the issue. Can we work out a system that
will work for all projects involved? What I am about to bring up is not
the same issues that Danny has with GCCisms but it has made me think
about our build system again.
WINE and Mingw both make use of some of the aspects of the
>Anybody got ideas?
You have winealsa.drv in your lib path and artsd is stoped, right?
>Is it a patent for a hrdware solution, or for software? If software then in
>Europe, at least in Germany and others, it wouldn't matter because
>softwarepatents are not possible (and hopefully never will).
Software patents are illegal in all the EU, and it will stay like that thanks to
the latest
>hell, if MS can get a patent on NTFS they can get a
>patent on anything.
I do remember reading that the WTO decided that APIs aren't patentable.
Daniel Marmier <[EMAIL PROTECTED]> writes:
> Are you talking about support for TLS in wine?
> If so, is that already assigned?
No, the problem is TLS support in glibc itself, since that bypasses
our pthread wrappers. We don't need to use glibc-style TLS in Wine
since we can use the Win32 TLS supp
Anyone had a look at this?
http://www.theinquirer.net/?article=12207
Tom
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> On October 18, 2003 07:04 am, Ferenc Wagner wrote:
>
>>> +char line[512], *cmd;
>>
>> Fixed size buffers are wrong...
>
> Oh come on, it's just a temp buffer to copy stuff through.
> It introduces no limitation.
Sorry, I was too quick here.
>>
Hello fellows,
Rolf Kabermater (from wine) and I (from Odin) need help.
Rolf has written a nice test-programm for many many test-cases (round
(45*4+40*2)*8*4) for shlfileop, based on my test-scripts with a one-case
test-program for shlfileop. With this faster program we had tested many
more cases
I am using MSDN July 2001.
Just look up WM_MDICREATE at the bottom of the page you have links to an
over-view and all important functions/messages.
Basically you:
- Create any frame window but call MdiFrameProc for default processing.
- Create a child MDIClient as you have seen. sub-class it or u
On October 19, 2003 11:10 am, Rein Klazes wrote:
> Now I spent some time creating EDIT windows, varying parameters (with or
> without text), varying styles including multilines even tested the edit
> part of a combobox. In all cases the WM_CREATE message return value
> turned out to be 1. So at th
Hi,
Sent to wine-devel as well: this might break some odd edit controls that
I did not catch.
This fixes masked edit controls used by applications created by Power
Builder, it fixes bug #807.
Power builder depends on the return value of the WM_CREATE message by
the EditWndProc to be != 0.
Now I
On October 19, 2003 07:58 am, Mike Hearn wrote:
> This implementation is obviously not complete, but it prints out the
> event log strings using MESSAGE, which is good enough for now.
Another option is to create a new debug channel (call it eventlog)
and output to it. This way we give people a bit
Jonathan Wilson wrote:
Currently, we have 3 different projects that are working towards windows
"compatibility".
We have ReactOS
We have WINE
and We have MingW-Runtime and w32Api (refered to as just MingW from now on)
The 3 projects have different goals but the same target. Microsoft
Windows and
Eric Kohl wrote:
Another issues are licenses and copyrights. IMO, public headers and import
libraries should not be licensed or copyrighted at all. They should be in
the public domain, so anybody can use them the way they want.
This is the only option that makes the most sense. Headers and import
Shachar Shemesh wrote:
Hi all,
I am trying to make an application work under wine. The app is
probably an MFC app, that defenitely uses MDI. The problem boils down
to this - it tries to create an MDI window by doing SendMessageA to a
message of type "WM_MDICREATE". Here's the catch - the class
Hi all,
I am trying to make an application work under wine. The app is probably
an MFC app, that defenitely uses MDI. The problem boils down to this -
it tries to create an MDI window by doing SendMessageA to a message of
type "WM_MDICREATE". Here's the catch - the class it wants to use is in
On Sat, 2003-10-18 at 23:15, Pavel S. Khmelinsky wrote:
> Hi!
>
> I try to run Soldat by wine and failed ( strange isn't it? :) )
> U can found this game at http://www.soldat.prv.pl/ .
IIRC Soldat uses some pretty nasty copy protection stuff that breaks
Wine - don't fully remember.
If you get a
"Vizzini" <[EMAIL PROTECTED]> wrote:
> Executive Summary
> -
> - Use MinGW for all public interface headers, i.e. everything that
> MinGW supports
> - Use non-OS-specific Wine libraries unmodified
> - Use portions of OS-specific Wine libraries (e.g. user32)
> - Keep it all str
On Sun, 19 Oct 2003 01:00:51 -0500, Sir Gregory M. Turner scribed thus:
> which ostensibly would seem to contradict your prognosis... (although I assume
> you are nevertheless correct -- this is not the root-dir configure, so maybe
> it's misleading me. I will poke at it again to see what gentoo
On Sat, 2003-10-18 at 19:38, Alexandre Julliard wrote:
> Mike Hearn <[EMAIL PROTECTED]> writes:
>
> > Alexandre - this is your area. Any ideas?
>
> Your glibc is using TLS. Support for that is not ready yet. Depending
> on your system you need to either set LD_ASSUME_KERNEL=2.4 or install
> anoth
"Jonathan Wilson" <[EMAIL PROTECTED]> wrote:
> IMO its a waste for both WINE and ReactOS to have 2 different
> implementations of MSVCRT.DLL/CRTDLL.DLL
> Is there any valid reason not to either remove one and have both projects
> use the other or to merge both and come up with one dll?
Wine has
Alexandre, please don't apply this patch (but you can apply my previous
one). After talking with Vitaliy, it seems this patch is not the right
fix. I'll send a new one later.
Max
On Sat, 2003-10-18 at 11:57, Maxime Bellengé wrote:
> This patch fixes a regression introduced by last Vitaliy Margole
IMO its a waste for both WINE and ReactOS to have 2 different
implementations of MSVCRT.DLL/CRTDLL.DLL
Is there any valid reason not to either remove one and have both projects
use the other or to merge both and come up with one dll?
35 matches
Mail list logo
