On Saturday 18 October 2003 12:38 pm, 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
another
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?
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 Margolen
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
another glibc
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 straight with
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
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
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
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
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
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
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
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
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 the
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 support
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.
+ while
Anyone had a look at this?
http://www.theinquirer.net/?article=12207
Tom
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.
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
Anybody got ideas?
You have winealsa.drv in your lib path and artsd is stoped, right?
--- 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;
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 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, codeweavers
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
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 you
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 the catch
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
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 to be a
28 matches
Mail list logo
