Hello Dimitrie,
Saturday, November 22, 2003, 1:02:00 AM, you wrote:
DOP> Here is a list of places where {Global,Local}ReAlloc() are used.
DOP> I'd like to replace them with Heap* functions where it is possible,
DOP> but before I do, I need to know where we need the old calls.
Btw: What's the diff
On September 23, 2003 02:47 pm, Eric Pouech wrote:
> didn't search hard enough
> in fact, I was searching in Win9x, where it isn't present, and only
> configured in .ini files.
> In NT, they seem to be stored in
>
> for win.ini in
> HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MCI Extensions
>
Title: Re: wn20031121_197.xml
> If I am not mistaken, I offered him commit access a while ago. He was
> content at the time to have my slow butt commit. The offer still
> stands.
Yeah.. maybe it's time I take you up on it.
Up until recently I didn't have reliable shell access. Now I'v
Gavriel State wrote:
Hi Tom,
No, that's not the case - every line of code that we've added into the
in the WineX tree that is not explicitly under the LGPL is distributed
under the AFPL. Again, from our license documentation:
Hi Gav,
I want to first off thank you for your reply.
I'm not sure if
On Fri, 2003-11-21 at 14:23, Shachar Shemesh wrote:
> On a totally different subject - wouldn't you say it was time to give
> Brian Vincent commit access to the web site?
If I am not mistaken, I offered him commit access a while ago. He was
content at the time to have my slow butt commit. The off
Vincent BÃron wrote:
Le ven 21/11/2003 Ã 14:44, Shachar Shemesh a Ãcrit :
Wouldn't you say that it's time to give Vincent commit access to the web
site?
That'd be Brian, not me.
Vincent
Luckily, it has recently rained, and so there is plenty of mud for my face.
Sorry about that.
On
On November 21, 2003 12:16 pm, Ferenc Wagner wrote:
> I've got a more or less standalone version which can run the
> tests and submit the results to a CGI script, if possible.
> It also differentiates between libwine and cross builds. I
> would be grateful for a review. One week point is its
> in
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> Speaking of which, I noticed you're hard at work at it, do you
> need a hand? If so, we need to coordinate a bit, it's just too
> easy to step on each other's toes.
Probably not worth the trouble, there aren't many calls remaining.
> Also, is it w
Wouldn't you say that it's time to give Vincent commit access to the web
site?
Brian Vincent wrote:
wn20031121_197.xml
-brian
Wine Traffic
Hi,
Next problem with Agent 2.0 beta.
The problem is when composing a message (email/usenet) and pressing the
escape key. Expected is a dialog to confirm whether you want to save the
message, not to save it or to cancel. Instead the dialog flashes and
disappears again and nothing happens.
Here
Lionel Ulmer wrote:
1. Should I add a new config option (something like RequireAlphaChannel)
- FWIW I hate this idea
2. Is it ever going to be possible to replace a wine Xwindows visual?
What is involved in doing this? This is the 'perfect' solution.
3. Can I default double buffering and alpha on
> I added this check the day I found out that any Mesa-based GL library
> returns a non-NULL function pointer from glXGetPointerAddress whatever the
> status of the extension ... which leads to crashes if one actually calls
> this function without checking first for the presence of the extension.
> 1. Should I add a new config option (something like RequireAlphaChannel)
> - FWIW I hate this idea
> 2. Is it ever going to be possible to replace a wine Xwindows visual?
> What is involved in doing this? This is the 'perfect' solution.
> 3. Can I default double buffering and alpha on regardles
Hi folks,
There are a few places in Wine where we're not using the
Heap*() functions, but rather the old {Global,Local}{Re,}Alloc()
ones. IIRC we need to do so in controls/edit.c for compatibility
with old Win16 code, but why do we do so in places like:
* print dialog
* ole32
* shell32
*
> Do you really need to lock all GL calls, or is it just to protect
> access to d3d internal structures?
I do not lock at the individual GL call level but rather at the 'internal
API' level (for example, to draw some primitives, I do not lock on each
glVertex call, but at the API function level w
On Fri, Nov 21, 2003 at 09:32:05AM -0800, Alexandre Julliard wrote:
> We should of course report the bug, but I don't see any reason not to
> put that workaround in, since it actually makes the code simpler, and
> I don't see how it would break anything since we check the function
> pointer anyway.
On November 20, 2003 08:45 pm, Alexandre Julliard wrote:
> Yes, and ultimately not only to get rid of the TSX functions but of
> all the explicit X11 locking too.
It would be nice to finish this before WineConf, this
way the circle is complete, we've been bouncing this idea last
conference, in San
On November 21, 2003 12:16 pm, Ivan Leo Murray-Smith wrote:
> make doc generates one big file, but this isn't what I want.
Do not pass the -u flag to the db2xxx tools.
--
Dimi.
I thought a simple 'KRun(KURL("SomeBinaryFilename"))'
should work, but it doesn't ?
(I get ld telling me that there was an undefined
reference to KRun::KRun(const KURL&...) !)
Please tell me/redirect me(just make sure that the
reference is working!) to an example where I can use
KRun in such a m
"Rolf Kalbermatter" <[EMAIL PROTECTED]> writes:
> My tests show that RemoveDirectory just as CreateDirectory rejects all
> paths which contain one of the wildcards ": * ? \" < > |" with error 123
> completely independent where that character occurs (not just in the path
> element which is created)
Le ven 21/11/2003 à 12:16, Ivan Leo Murray-Smith a écrit :
> Hi list,
> how can I build the wine docs in different little files (index.html,
> wine-stats.html and so on, like the docs for download on the web site) instead
> of one big file?
> make doc generates one big file, but this isn't what I w
Lionel Ulmer <[EMAIL PROTECTED]> writes:
> Well, this poses the question : what should we do regarding broken libraries
> Wine depends upon ? Add 'incorrect' code in Wine (although in this case,
> it's not THAT incorrect :-) ) or report the bug to the library maintainers
> and wait for them to fix
Lionel Ulmer <[EMAIL PROTECTED]> writes:
> This means that I will have to change the usage of the X11 critical section
> in the D3D code by one of our own (basically, we 'misuse' a bit this crit.
> section to prevent two threads doing GL calls at the same time - something
> that games like Dungeon
Hello,
> I don't understand, sorry. ATL is a set of C++ convenience wrappers around
> COM and is redistributable. All the infrastructure for displaying embedded
> OLE/AcitveX controls is already in Wine... do you think we're missing
> something?
Humm, I don't know, I have a dll "atl.dll" with thi
I acquired wine from source (version 20031118) just this morning, and I
ran into some issues with an error stopping make in /dll/glu32/, the
last few lines of the output:
--//--
rm -f libwine_unicode.so.1 && ln -s unicode/libwine_unicode.so.1
libwine_unicode
.so.1
gcc -shared -Wl,-Bsymb
Hi there,
I've got a more or less standalone version which can run the
tests and submit the results to a CGI script, if possible.
It also differentiates between libwine and cross builds. I
would be grateful for a review. One week point is its
integration into the build system: I h
Hi list,
how can I build the wine docs in different little files (index.html,
wine-stats.html and so on, like the docs for download on the web site) instead
of one big file?
make doc generates one big file, but this isn't what I want.
Ivan.
Ok, my fault.
There is no error in the patch of wine/dlls/ntdll/path.c which was checked
in.
The patch has the line
+if (!newname) RtlFreeHeap(GetProcessHeap(), 0, name);
instead of that I read
+if (newname) RtlFreeHeap(GetProcessHeap(), 0, name);
which
I have successfully compiled sources of a Windows application, but
when starting up, it tries to locate and link to a windows dll
to access some C library functions:
...
err:module:import_dll No implementation for cw3230.DLL._strlen imported
from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview
Tom wrote:
Hello Gav,
So in other words these are the AFPL components.
# dlls/ddraw (libddraw.so)
# dlls/dsound (libdsound.so)
# dlls/dinput (libdinput.so)
# dlls/d3dgl (libd3dgl.so)
# dlls/d3d8 (libd3d8.so)
# dlls/dinput8 (libdinput.so)
So I take it everything else should be taken to be X11?
If
I try to find a good font for application.
But all linux fonts looks not so good.
The best font that I found is cronyx, but it is not support european
code page.
Does anybody know where I can find a font like cronyx ?
Thanks.
* Dmitry Timoshkov <[EMAIL PROTECTED]> on Fri, Nov 21, 2003:
> "Marcus R. Brown" <[EMAIL PROTECTED]> wrote:
>
> > * dlls/imagehlp/access.c:
> > Marcus R. Brown <[EMAIL PROTECTED]>
> > Implement ImageRvaToSection() and ImageRvaToVa().
>
> Why not simply forward them to ntdll where the real implem
"Marcus R. Brown" <[EMAIL PROTECTED]> wrote:
> * dlls/imagehlp/access.c:
> Marcus R. Brown <[EMAIL PROTECTED]>
> Implement ImageRvaToSection() and ImageRvaToVa().
Why not simply forward them to ntdll where the real implementation
resides instead of duplicating code?
--
Dmitry.
Current code builds on my system.
On Friday 21 November 2003 09:43, Rolf Kalbermatter wrote:
> I would actually agree with Alexandre here, but W2K at least behaves
> differently.
> My tests show that RemoveDirectory just as CreateDirectory rejects all
> paths which contain one of the wildcards ": * ? \" < > |" with error 123
> com
[Ralf Juengling]
> > What is the status of the include files in msvcrt?
[Alexandre Julliard]
> They should work just fine. Make sure you also import msvcrt if you
> use the headers.
[Ralf Juengling]
> > So my solution to make it compile was to remove wine's
> > 'math.h'. That's why I would say t
Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> > As for the invalid characters, [Create|Remove]File[A|W] only check
> > for '?', '*', which I just copied for [Create|Remove]Directory[A|W].
> > I take it you will accept a patch that also extends the checks in
> > [Create|Remove]File*?
>
> Yes, a
> Yes, and ultimately not only to get rid of the TSX functions but of
> all the explicit X11 locking too. These days I think it's reasonable
> to assume that the X libraries are thread safe.
This means that I will have to change the usage of the X11 critical section
in the D3D code by one of our o
Jacek,
It seems your patch was line-wrapped (which is not a good thing). Moreover,
it's not necessary to add the patch against 'configure', you just need to
tell Alexandre in the patch mail that he needs to re-generate it himself
when comitting.
Lionel
--
Lionel Ulmer -
On Thu, Nov 20, 2003 at 11:50:13PM +0100, Daniel Skorka wrote:
> This patch fixes a problem with bad OpenGL libraries wich uncorrectly
> report the Extensions they support. Those libs would incorrectly report
> not supporting glXGetProcAddresARB, on which wine relies for OpenGL
> extension support.
40 matches
Mail list logo
