Jonathan Wilson <[EMAIL PROTECTED]> writes:
> ReactOS uses linker magic.
> My point is that there is no valid reason for the WINE code in
> kernel32 not to use RtlAllocateHeap since the WINE kernel32 code is
> only intended to run on ReactOS (where RtlAllocateHeap is available)
> and WINE (where R
Andrew de Quincey <[EMAIL PROTECTED]> writes:
> However, if no one minds, I think I'll still implement the stuff I was doing.
> I found being able to examine the call tree with ballpark figures of how long
> was spent in each call was very invaluable.
Note that the relay debugging adds a huge o
On December 1, 2003 04:51 pm, you wrote:
> ChangeLog
> Add support for editing strings.
Please ignore this for now, I want to change a few things.
I'll resubmit in a few minutes.
--
Dimi.
On December 1, 2003 06:29 pm, Steven Edwards wrote:
> The ReactOS and WINE regedits are a little out of sync. Can you
> incorporate this in to your next patch?
OK,
but the bulk of it is this:
+struct {
+ char *Name;
+ ULONG Id;
+} Messages[] =
+{
+ {"WM_ACTIVATE", WM_ACTIVATE},
...
+ {"W
ReactOS uses linker magic.
My point is that there is no valid reason for the WINE code in kernel32 not
to use RtlAllocateHeap since the WINE kernel32 code is only intended to run
on ReactOS (where RtlAllocateHeap is available) and WINE (where
RtlAllocateHeap is available). Therefore, re-writing
Andrew de Quincey <[EMAIL PROTECTED]> writes:
> + if (brush->lbHatch && (brush->lbStyle & ~(BS_SOLID|BS_HOLLOW)))
> + FIXME("Hatches not implemented\n");
BS_SOLID etc. are not flags, you can't test them that way.
--
Alexandre Julliard
[EMAIL PROTECTED]
Hello Dan,
--- Dan Kegel <[EMAIL PROTECTED]> wrote:
> Pure, fresh install of wine-20031118 from sources on
> a dual processor Red Hat 9 machine.
> Installed winzip, used it to unpack OpenOffice1.1.0.
> Installed OpenOffice1.1.0. Install went fine.
> Found no 'soffice.exe' of any sort, so ran Winef
--- Jonathan Wilson <[EMAIL PROTECTED]> wrote:
> No, thats not brain damaged.
> Thats the way Microsoft does things. (at least on XP)
> HeapAlloc doesnt exist at all, all it is is a forwarder to NTDLL.
> Therefore, all the code in kernel32 should just call RtlAllocateHeap.
> Given that kernel32.dll
> Ahhh forget the HeapAlloc stuff. That was my fault. Someone decided in
> a very drain-bamaged way to forward all the Heap* calls to the RtlHeap
> calls in the spec file rather than in the source so anytime we try to
> port Winehq sources for kernel32 that use HeapAlloc I was running in to
> probl
--- "Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote:
> On December 1, 2003 02:44 pm, Eric Pouech wrote:
> > That would be doable yes (at least in kernel32). In other DLLs,
> it's
> > more arguable, especially if we want to test them on non NT
> systems.
>
> Agreed, I see no need to make our DLLs depe
--- "Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote:
> Agreed, I see no need to make our DLLs depend on ntdll. And I don't
> understand why you guys need to change the source for such a trivial
> (and useless) 'optimization'. Even within kernel32 I'd still use
> the Heap*() functions for consistency,
Hello
I'm considering getting an Opteron. With this being a 64bit CPU I
wondered if there would be any issues with using WINE to make use of
win32 software on this 64bit CPU.
Kind regards
JG
p.s. I'm not subscribed to this list from this email address, so please
include my email address in
Hello Dimi,
--- "Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote:
> I figured I should so something a bit more "useful" (in light of
> the 0.9 release), so here is the first attempt. It's not too much,
> and not too good, but after looking at the code, it needs some
> major cleanup before I can do any
On Monday 01 December 2003 22:35, Andrew de Quincey wrote:
> On Monday 01 December 2003 20:16, Mike Hearn wrote:
> > On Mon, 2003-12-01 at 12:49, Andrew de Quincey wrote:
> > > Hi, the last thing I have to do with the profiling stuff is the
> > > trickiest: To decide what is the best way to determi
On Monday 01 December 2003 20:16, Mike Hearn wrote:
> On Mon, 2003-12-01 at 12:49, Andrew de Quincey wrote:
> > Hi, the last thing I have to do with the profiling stuff is the
> > trickiest: To decide what is the best way to determine the times.
>
> It might be worth using oprofile, apparently in 2
On Monday 01 December 2003 20:33, Dimitrie O. Paun wrote:
> On December 1, 2003 03:26 pm, Alexandre Julliard wrote:
> > That's not possible, such a simple function cannot take 168us, unless
> > you have a 1Mhz CPU... How did you measure it?
>
> I think he measured it across the call:
>
> start
>
Hi Jeremy,
As indicated in the license file distributed with our sources, which the license
permits non-commercial redistribution of WineX binaries built from CVS, we ask
that people not do this as it affects our ability to finance further development.
See the license file on our CVS server for mo
Andrew de Quincey <[EMAIL PROTECTED]> writes:
> CharNextW takes on average 168.5340us. However it is called 12396 times when
> opening the save box for IDA. As I said, IDA supplies quite a large string of
> filter expressions to the save box. This results in a total time of
> 2089146.9655us bei
Hans Leidekker <[EMAIL PROTECTED]> writes:
> What do you mean by 'access' here? Being able to read from the file?
> Write to it? Anything else like copying it or moving it?
Opening an existing file or directory should work. Creating a
non-existing file with a name containing wildcards should fail
On December 1, 2003 03:26 pm, Alexandre Julliard wrote:
> That's not possible, such a simple function cannot take 168us, unless
> you have a 1Mhz CPU... How did you measure it?
I think he measured it across the call:
start
CharNextW
end
but it still doesn't add up. If his measurement is c
On December 1, 2003 02:44 pm, Eric Pouech wrote:
> That would be doable yes (at least in kernel32). In other DLLs, it's
> more arguable, especially if we want to test them on non NT systems.
Agreed, I see no need to make our DLLs depend on ntdll. And I don't
understand why you guys need to change
On Mon, 2003-12-01 at 12:49, Andrew de Quincey wrote:
> Hi, the last thing I have to do with the profiling stuff is the trickiest: To
> decide what is the best way to determine the times.
It might be worth using oprofile, apparently in 2.6 at any rate it works
well with Wine.
> The problem is..
Steven Edwards <[EMAIL PROTECTED]> writes:
> Also I was looking at the HeapAlloc stuff in WINE and code we have
> ported from ReactOS such as the FormatMessage function in kernel32.
> Doesnt kernel32 HeapAlloc and friends map on top of ntdll RtlHelpAlloc?
> Can we submit patches to WINE so that ev
Hello!
Am Mon, 2003-12-01 um 21.02 schrieb Roderick Colenbrander:
> Hi,
>
> The problem seems to be a bug in the cpu code. You had almost found it
> yourself. If you had scrolled a few more lines down you would have seen that
> we are already using /proc/cpuinfo. I think that bug is in the foll
Hi,
The problem seems to be a bug in the cpu code. You had almost found it
yourself. If you had scrolled a few more lines down you would have seen that
we are already using /proc/cpuinfo. I think that bug is in the following
piece of code. When the cpu is a p2/p3/p4/p-m/ppro we set wProcessorLe
On Mon, Dec 01, 2003 at 08:22:49PM +0100, Olaf Leidinger wrote:
> Hello!
>
> Once I tried to install the win32 version of gimp-1.3.xx-i686 using wine
> and the installer refused to install because gimp was only compiled for
> newer processors. The author told me, that he uses the GetSystemInfo
> f
Steven Edwards wrote:
Hello,
We are looking at porting more code from WINE to ReactOS and I am
having trouble understanding the need for libwine_unicode as a shared
library. Some of the functions that it exports such as CompareString
are implemented in ntdll as RtlCompareString and then also used i
Hello!
Once I tried to install the win32 version of gimp-1.3.xx-i686 using wine
and the installer refused to install because gimp was only compiled for
newer processors. The author told me, that he uses the GetSystemInfo
function to get the data he needs.
Running a modified MS-example on wine I g
On Sunday 30 November 2003 03:07, Alexandre Julliard wrote:
> It's not invalid on Unix, that's the whole point. If we make them
> illegal right away it means you won't be able to access legally named
What do you mean by 'access' here? Being able to read from the file?
Write to it? Anything else l
Mike Hearn <[EMAIL PROTECTED]> writes:
> See if you can get a +font trace when synchronous mode is switched on
> (see the config file), and a backtrace. That might help figure out
> what the problem is.
Have you had a chance to look at the backtrace?
Thanks,
Erik.
On Sun, 2003-11-30 at 01:51, Tom wrote:
> I would send them to wine-patches under WineHQ:
> Then if Jer wants to pick them up and put them in the que they would be
> there..
> Is this correct?
Yes, that is correct. Use the current screenshots section as a guide for
how I prefer the screenshots to
On Fri, 2003-11-28 at 17:59, Brian Vincent (C) wrote:
> If no one objects I'd like to post more stuff to the front
> page news section. In some ways it will repeat items that
> will be covered in more detail in each WWN issue. The idea
> is to keep more current with Wine-related press releases
>
I'd be happy to add you to the links. I want to give someone the chance
to comment on this before I do.
Any objections?
On Sun, 2003-11-30 at 16:14, Ivan Leo Murray-Smith wrote:
> As you probably already know, Marek Lipovcan and I build RPMs of WineX for Linux
> Red Hat, Suse, Mandrake and compat
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
> How do I put Unicode there? I need to put in characters that, by
> definition, are taken from very varied parts of the unicode charset table.
> If that problem is *easilly* solveable, I'll glady do the change.
Have a look at one of unicode only loca
Hi, the last thing I have to do with the profiling stuff is the trickiest: To
decide what is the best way to determine the times.
To get times that are useful, I'm using the RDTSC opcode (which returns the
number of CPU clock cycles since the machine was powered on).. basically I've
added a cou
Strange, it applies just fine here.
On Mon, 2003-12-01 at 04:22, Sylvain Petreolle wrote:
> Your patch fails being applied to cvs at the moment...
> nothing critical though, this is only the license part of
> dlls/system32/systray.c.
>
> ***
> *** 1,11
> /*
> - *Systray
>
On Monday 01 December 2003 09:32, Andrew de Quincey wrote:
> > In other words, I don't think the patch is acceptable. What I'd suggest:
> > -- figure out why the real CharNextA() is slow, and try to fix that
> > -- figure out why it takes so long to call CharNextW()
>
> As I said originally, it
> In other words, I don't think the patch is acceptable. What I'd suggest:
> -- figure out why the real CharNextA() is slow, and try to fix that
> -- figure out why it takes so long to call CharNextW()
As I said originally, its not that CharNextW/CharNextA are particularly slow,
its the numb
On Sunday 30 November 2003 01:23, Dimitrie O. Paun wrote:
> On November 29, 2003 06:27 pm, Andrew de Quincey wrote:
> > I've replaced the calls to CharNextA()/CharNextW() with array increments
> > and a local static function. This knocks 3.5 seconds off the file open
> > dialogue in IDA.
>
> Well,
Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
Please explain:
1. What kind of a resource should I use, in your opinion?
String resources.
2. How should I select which resource to load, given a specific locale?
Font charsets doesn't depend on the current
40 matches
Mail list logo
