On Wed, 8 Oct 2003, Francois Gouget wrote:
>
> I did not know about w3m before I saw this patch. More well-known and
> widely spread alternatives are lynx and links which are command-line
> compatible with w3m. So I propose to also look for them.
Yeah, I didn't know about w3m either. Wouldn't a
On Wed, 8 Oct 2003, Oleg Prokhorov wrote:
> Change-log:
> fix wine code depended on
That's cool, but we need to somehow manage this. There are almost
300 occurences of memory reallocation, and we need to somehow
keep track of what was reviwed/fixed etc., otherwise we risk
missing quite a few.
On Wed, 8 Oct 2003, Alexandre Julliard wrote:
> Actually it seems there is now (finally) a docbook2txt tool, we should
> probably use that instead.
Indeed.
ChangeLog
Dimitrie O. Paun <[EMAIL PROTECTED]>
Use docbook2txt to generate the text output instead of adhoc ha
On Wed, 8 Oct 2003, Steven Edwards wrote:
> For the most part this is all it seems to do. Differnt mertics and
> Windows styles. You can see examples of this by looking at the sources
> for the edit control. With the common diaglogs there is code that
> implements a Win31 theme if a you want to us
On Wed, 8 Oct 2003 [EMAIL PROTECTED] wrote:
This patches are so hard to review. Not only are they
not inlined, but they are attached as Application/OCTET-STREAM.
This means I have to type about 8 keystrokes to open
them in pine. Please, pretty please, try to inline them.
If this doesn't wokr (have
On 8 Oct 2003, Daniel Marmier wrote:
> Fixed warnings with gcc option "-Wwrite-strings".
BTW, how far away are we from always compiling with -Wwrite-strings?
--
Dimi.
On October 8, 2003 05:51 pm, [EMAIL PROTECTED] wrote:
> So what I'm gonna do in the future is inline patches that won't get
> line wrapped and attach the others the way I use too. Hopefully,
> most of them will be inlined.
Thanks Dave,
This is very kind of you, but I think this is too much effort
On October 9, 2003 08:11 am, Sylvain Petreolle wrote:
> As an alternative, if welcome on the list, we can zip/bzip the patch,
> this way they wont be mangled by Notes.
No, this is most definitely not welcome on the list...
--
Dimi.
On Thu, 9 Oct 2003, Shachar Shemesh wrote:
> I think I can do that. What I suggest:
> Attachments must be either .diff or .patch. If you want, they can be bz2
> or gz compressed. Mime type is disregarded. Also, the mail must be
> non-HTML (or, at least, must have a text only component). Emails t
On Thu, 9 Oct 2003, Shachar Shemesh wrote:
> I don't think that's a good idea. I think "looks like text" is
> difficult. I don't know how Japanese resources look like, nor how
> Keyboard layouts in Spanish. I'd rather go with the file extension.
file(1) is your friend. Mime types are completely
On Thu, 9 Oct 2003, Bill Medland wrote:
> Having just fallen over this might I suggest that the configure check also
> checks for lynx; if lynx is not installed then even though docbook2txt is
> present it fails.
>
> Or is there a version of docbook2txt that doesn't depend upon lynx?
I have no
On October 9, 2003 08:50 pm, Alexandre Julliard wrote:
>We can now use the standard DllMain as entry point.
Cool, what about the one in user32:
[EMAIL PROTECTED] wine.src]$ grep DLLMAIN `find -name "Makefile.in"`
./dlls/user/Makefile.in:DLLMAIN = [EMAIL PROTECTED]
It's the last one, we
On October 9, 2003 09:58 pm, Geoff Thorpe wrote:
> look/feel/use, like "wine-cvs". I would have personally thought that
> attachments make more sense, because separating patches from text can be
> ambiguous and it's not as easy to send multiple patches (eg. when
> submitting two alternative patches
On Fri, 10 Oct 2003, Geoff Thorpe wrote:
> The submission and processing of patches is not something totally alien to
> me, though the specific history and conclusions reached w.r.t. wine mail
> lists is. That said, you needn't crusade the inlining argument by
> dispatching me to the list archi
Hi folks,
As I said, there are over 200 instances of {Local,Global,Heap,}ReAlloc that
need reviewing and/or fixing. We need to keep a close eye on these, so we
don't let some fall through the cracks.
I've compiled a list of all the places that need attention. We currently
have 225 such places. Be
On October 10, 2003 08:17 pm, Steven Edwards wrote:
> Here are the templatates I have stated on for the website regarding
> porting WINE to other CPUs and Compilers. Please send any flames about
> spelling/grammer to \Device\NUL as I this is a work in progress. If you
> have worked on any of the fo
On October 11, 2003 10:22 am, Ivan Leo Murray-Smith wrote:
> I sent this patch
> http://www.winehq.org/hypermail/wine-patches/2003/10/0064.html
> and can't think a reason in the world for it not to be applied, have I done
> something wrong or what?
Well, for one Jer is not very responsive to wineh
Hi folks,
Oleg has been doing a lot of good work, and we are now
down to 73 HeapReAlloc and 73 non-HeapReAlloc entries
to review. I'm still not sure how the comctl32.ReAlloc()
should behave, any help in getting that resolved would
be highly appreciated.
Here is the update list:
./controls/edit.c
On October 11, 2003 03:42 am, Jerry Jenkins wrote:
> > +chardevice[] = "hw";
> I think it should be
> static char device[] = "hw";
Why is that? In fact, I think it shouldn't, if it
gets modified during the call, we'll end up passing
garbage values on su
On October 11, 2003 02:50 am, Dimitrie O. Paun wrote:
> ...+-+
> ...|Compilers |Headers | OS| Architecture
> |
> ...| MSVC | MinGW | SunCC | MSVC | MinGW | NetB
On October 12, 2003 01:00 am, Jerry Jenkins wrote:
> If we keep device[], we need the static
> keyword to make winealsa work.
Why do we need the static?
--
Dimi.
On October 11, 2003 06:40 pm, Steven Edwards wrote:
> I really dont want to have a ReactOS column in the list as the ReactOS
> project is planning on properly branching winehq cvs when WINE reaches
> reaches 0.9/1.0.
Why would you want to branch, I would have thought that you want to
keep a common
On October 11, 2003 03:01 pm, Alex Pasadyn wrote:
> I'm sending this in two parts because I added some files and can't get
> cvs diff to have them show up.
Of course, cvs diff will ignore these files. You need to add them manually
to diff. To do so, you do:
$ cvs diff dlls/x11drv > randr.diff
On October 11, 2003 06:44 pm, Steven Edwards wrote:
> Can you send me a example in HTML of how you want to layout
> Headers/OS/Compilers? I am having trouble getting it from looking at
> the plain text.
OK, attached.
> > What's up with the 95%, why not 100%? :)
>
> 95% is with Wine Headers. I was
On October 13, 2003 09:09 am, Ivan Leo Murray-Smith wrote:
> Until then, winesetuptk is the only easy way of
> configuring wine, and I have no intention of telling users
> "Go and edit the config file and add this and remove that and make a system
> directory inside the windows directory that's in
On October 13, 2003 10:13 am, Ivan Leo Murray-Smith wrote:
> In what way doesn't it work?
See Vincent's message. I quote:
"The problem is that the tool hasn't really followed Wine development
(for example, removal of $VAR-style variables from config file), and
some users experience problems becau
On October 14, 2003 07:59 am, Mike McCormack wrote:
> Just incase anybody is interested, here is a regression test for
> mailslots. There's not much point to include it into Wine until we
> support mailslots properly (which I'm working on).
Why not include it as a todo_wine{} in the tree? (if you
On October 12, 2003 03:03 pm, Steven Edwards wrote:
> Well yes in the "should" work out of the box under ReactOS but most
> dont work perfectly atm due to bugs in our Win32k/GDI/User32
> implementaion. I agree it would be nice to keep better track of this on
> the WINE porting page and I do want to
Only 33 non HeapReAlloc entries remain:
./controls/edit.c: hloc32W_new = LocalReAlloc(es->hloc32W,
alloc_size, LMEM_MOVEABLE | LMEM_ZEROINIT);
./controls/edit.c: if ((hNew32W = LocalReAlloc(es->hloc32W, alloc_size,
LMEM_MOVEABLE | LMEM_ZEROINIT))) {
./controls/edit.c:
We still have 72 HeapReAlloc() entries to validate:
./dlls/kernel/toolhelp.c:notifys=(struct notify*)HeapReAlloc(
GetProcessHeap(), 0, notifys,
./dlls/kernel/toolhelp.c:notifys=(struct notify*)HeapReAlloc( GetProcessHeap(), 0,
notifys,
./dlls/kernel/local16.c:ptr = HeapReAll
On October 13, 2003 04:20 pm, Alex Pasadyn wrote:
> I think there are two separate problems that are being addressed, and it
> makes sense to have and document two stages of configuration. Step one
> doesn't ask too many questions (really just whether you want to use an
> existing "C" drive or not
On October 14, 2003 03:11 pm, Jason Filby wrote:
> I agree that forking should be avoided at all costs. Of course it
> will be unavoidable for lower level DLLs such as user32.
You are right, ReactOS will probably need it's own ntdll, and
maybe kernel. But for user32 and gdi32, I am hoping you ca
On October 16, 2003 12:02 am, Alexandre Julliard wrote:
> Actually it's my version that is too old, it's one from XFree86 4.2
> and the Xrender call has been added after that, so it seems we don't
> have much choice. I'll put it back in the configure check for now, but
> we'll need to load libXrand
On October 15, 2003 11:21 am, Jason Filby wrote:
> This sounds good to me. As you said, it seems like headers are the
> big blocker here.
For my info, what's the problem with the headers? What headers are
you using? If not Wine's, why not? It seems we have better headers
than then w32api guys...
On October 15, 2003 08:09 pm, Kevin Koltzau wrote:
> One possible solution would be to call the PROFILE_* functions (which are
> located in kernel/profile.c) directly which seem to work in a way that
> would make this very easy, but overall sounds like a very bad idea...
Well, it is, it breaks DLL
On Thu, 16 Oct 2003, Lionel Ulmer wrote:
> Well, and if the game starts a second process and you fall in the 'Desktop
> mode is buggy' problem :-) ?
OK, but in this case we should have it on by default, and it will not
be exposed in winecfg, you'll need to use regedit/vim/emacs/etc. to
control it
On Thu, 16 Oct 2003, Steven Edwards wrote:
> I dont know if better is the right word. WINE has more compleate
> headers but they are not the most correct. The w32api people are very
> anal (No Offence Danny) about getting changes in to the package. I have
> almost never found where something is wr
On Thu, 16 Oct 2003, Steven Edwards wrote:
> I have rebuilt a few engines in my day and this has been like trying to
> take parts from a BMW and use them on a Honda. It just doesnt work most
> of the time. Dont get me wrong it should "just work". All of the
> interfaces should be the same but
On Thu, 16 Oct 2003, Subhobroto Sinha wrote:
> Sorry, but it's the WHOLE file.
> I have changed the original file so much that to
> submit a proper patch I need an unmodified
> "shelllink.c" (I do have a backup, but where was that
> ?)
OK, here is the corresponding patch:
Index: dlls/shell32/sh
On Fri, 17 Oct 2003, Brian Vincent wrote:
>
> wn20031017_192.xml
There's still something wrong with the sorting:
The sorting looks odd:
--
Dimi.
On October 18, 2003 07:04 am, Ferenc Wagner wrote:
> > +#include
> > +#include
>
> Do we really need it twice?
Of course not :)
> > +while (1)
> > +{
> > +va_start(ap, fmt);
> > + n = vsnprintf (p, size, fmt, ap);
> > + va_end(ap);
> > +if (n > -1 && n < size) return
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
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
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
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 20, 2003 02:55 am, Rein Klazes wrote:
> I cannot imagine the conformance here to be accidentally "lost". I am
> not against conformance tests in general, but to protect such simple
> one-line functionality seems to me a waste of the effort.
Right, but the test would also tell us if all
On October 20, 2003 01:49 am, Vitaliy Margolen wrote:
> Do you mean I need to write some test program? I do have one, written in
> Delphi. I can send it in, or put on the web site and post a link here.
> Only it's not exactly nice program. Just something to test few things
> about tab control. Her
On October 21, 2003 12:43 am, Vitaliy Margolen wrote:
> I'm not exactly sure how such a test will work. It involves graphical
> components. Unless there are some way to make test see what's on the screen
> I can't think of a way how to do this.
Right, graphical tests are tricky, and it's not clear
On October 19, 2003 12:30 pm, Tom wrote:
> Anyone had a look at this?
> http://www.theinquirer.net/?article=12207
Cool, add it to the Press page.
Also, Tom, for the status pages:
-- Wine Resource Compiler: mark it as 90% done, it's still
missing stuff (Unicode files, some seldom used res
On October 21, 2003 09:00 am, Rein Klazes wrote:
> See? You are looking for an if-else-statement yourself. Perhaps there is
> not one. And if there is, it may test numerous other things then the
> Windows version.
I am not. But knowing is various Windows versions are consistent in
certain behavior
On October 19, 2003 04:28 am, Jonathan Wilson 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?
For
On 21 Oct 2003, Vincent Béron wrote:
> This is the current summary of Wine translations.
>
> It lists languages for which at least one resource exists.
>
> It can be found here:
> http://mecano.gme.usherb.ca/~vberon/wine/translation
This is great Vincent, but we need to put all this on one
big
On Tue, 21 Oct 2003, Ferenc Wagner wrote:
> It is a shame, but I can not apply your patch... It gives:
Sorry about that, maybe I should submit a new patch. I'll
do so when I get home, meanwhile here is a tar.gz of the
new files.
--
Dimi.
winetests.tar.gz
Description: GNU Zip compressed data
On October 21, 2003 07:43 pm, Ferenc Wagner wrote:
> Thanks, that is fine. I came across a webpage
> http://www.websteves.com/win32asm/datrsrc.htm
> stating that DISCARDABLE, LOADONCALL etc. are
> not needed anymore. Do we still need them?
Good point, I'll get rid of them.
--
Dimi.
On October 21, 2003 11:07 pm, Alexandre Julliard wrote:
> Patch:
> http://cvs.winehq.com/patch.py?root=/home/winehq/opt/cvs-commit&id=9836
We've changed the cvsroot, and it reared it's ugly head. Can we either
(1) create a symlink
On 23 Oct 2003, Jeremy White wrote:
> Further, I think it may be time to recognize that cool looking
> forums are what users expect; that mailing lists and newsgroups
> are really becoming the 'old' way of doing things.
I for one don't think highly of other forms of forums, but this
is not the is
On 23 Oct 2003, Jeremy Newman wrote:
> The software I mentioned to Jer that we could implement is
> Phorum. http://phorum.org/ I've played with it in the past,
> and integrating it into the current site is dead easy.
Yes, something like this I had in mind, so that people can
comment on the story
On October 21, 2003 05:07 pm, Vincent Béron wrote:
[sorry for the late reply, I thought I did, but I didn't :)]
> Would a row for each combination resource type+ID be too much?
No, I think that's just perfect to start with. Would be nice to
have some DHTML that allows expansion and collapsing per
On October 26, 2003 11:48 am, Uwe Bonnes wrote:
> +if (TRACE_ON(relay))
> + {
Not yet another formatting style, please...
--
Dimi.
On Tue, 28 Oct 2003, Steven Edwards wrote:
> Is the HeapAlloc/ReAlloc stuff being tracked anywhere? I think it is
> the cause of a lot of problems I have with shell32 under Windows and
> ReactOS. Applications linked to wine shell32.dll under Windows2000 run
> fine but when you exit they get illiga
On Tue, 28 Oct 2003, Alexandre Julliard wrote:
> Parts of it are merged already, I'm working on the rest. It still
> needs a bit of work because the current implementation in Crossover
> depends on a wrapper script that we don't have in WineHQ. Also note
> that you will need to use --with-nptl to
Hi folks,
We have a problem with 'make install' in the libs dir.
More explicitly, after a 'make & make install', I have
this in /usr/local/lib:
[EMAIL PROTECTED] unicode]$ ls -l /usr/local/lib/libwine*
-rw-r--r--1 root root 319332 Oct 27 12:01 /usr/local/lib/libwine_port.a
lrwxrwxrw
On Wed, 29 Oct 2003, Alexandre Julliard wrote:
> Yes, and it seems to work fine here. Could you show us the exact
> commands you ran and the relevant make output?
Well, I did a standard build:
configure --with-nptl --silent && make -s depend && make -s
than installed it (as root):
make -s
On Wed, 29 Oct 2003, Alexandre Julliard wrote:
> My guess is that ldconfig has messed with the symlinks.
Maybe because I have the old libwine*.so.1.0 in there...
I'll get rid of them, sorry for the false alarm.
--
Dimi.
On October 29, 2003 08:44 am, Adam Gundy wrote:
> A new tarball of valgrind modified to work with WINE is available from the
> valgrind home page:
>
> http://developer.kde.org/~sewardj/
> http://developer.kde.org/~sewardj/valgrind-20031012-wine.tar.bz2
>
> this is based on the latest stable val
On October 31, 2003 05:32 am, Mike Hearn wrote:
> I think it does as of the latest glibc, at least it's marked as "done"
> on their TODO list.
So we can stick Dan's implementation in libs/port, and do a
configure check for it...
--
Dimi.
On October 31, 2003 05:38 am, Adam Gundy wrote:
> that looks unlikely at the moment :-(
Darn. Even if we have to provide a switch (like --wine)
to valgrind? That would be so much better than a different
binary. What's the problem, BTW?
--
Dimi.
On October 31, 2003 02:41 am, Gregory M. Turner wrote:
> BTW, note that transports like http, tcp, etc, could allow wine to do DCOM
> without resolving the "priveleged ports" issue (at least for fixed
> endpoints) of course, our wire protocol is way off and will need fixing
> before that's poss
On October 30, 2003 07:28 pm, Ferenc Wagner wrote:
> > -if (n > -1 && n < size) return p;
> > - size = min( size*2, n+1 );
> > +if (n > -1 && (size_t)n < size) return p;
> > + size = min( size*2, (size_t)n+1 );
>
> Once at it, could you please explain to me what the hell is
On November 3, 2003 06:09 am, Ferenc Wagner wrote:
> In libc-2.1 and later, yes it should. According to MSDN
> (and pre-2.1 libc docs), it should not.
OK, so we need to care about n not being the size of the
required buffer.
> Seems like this is the case under Windows. Not under any
> reasonab
On November 3, 2003 08:01 am, Ferenc Wagner wrote:
> This will be a windows application after all... Running on
> native Windows. We can not use Unixism, or can we? By the
Yes, but it can be a Winelib app as well. Theoretically we
should use only stuff that is portable between libc and msvcrt.
On November 3, 2003 05:35 am, Mike Hearn wrote:
> Is there a Wine wiki anywhere?
Even if there is, if you don't know about it, it just shows
it's way to hidden to be useful. We need on nicely integrated
into WineHQ, with a fair amount of visibility.
--
Dimi.
On November 2, 2003 04:26 pm, Andreas Mohr wrote:
> + * Win31 0x8a03
> + * Win95 0xc004
> + * Win98 0xca04
> + * WinME 0xc0005a04
> + * NT351 0x04213303
> + * NT4 0x05650004
> + * Win2000 0x08930005
> + * WinXP 0x0a280105
Wouldn't these fit better in a unit test? :)
--
On Mon, 3 Nov 2003, Jeremy White wrote:
> I think searchable forums and well written FAQs are the way to go.
Mailing list archives are basically useless for the type of things
that Mike referes to. The information is much too scattered to have
a decent chance of finding anything relevant. Event i
On November 8, 2003 05:47 am, Gerald Pfeifer wrote:
> +#if USHRT_MAX > DATE_MAX
> if( uiIn > DATE_MAX )
Please find a non-#if solution. It's too minor to justify
the resulting ugliness.
--
Dimi.
On November 9, 2003 02:10 am, Sylvain Petreolle wrote:
> alsa09.diff must be applied to allow compilation with alsa 0.9.
Please do not send more than one patch per email, and do not
compress them. All this makes it hard on other people to
review them (or apply them, in Alexandre's case). Check out
On Mon, 10 Nov 2003, Mike Hearn wrote:
> What do people think? Good plan? Bad plan?
Never used linuxquestions.org before, but it seems to be a decent site.
I think it's a good start for such a forum, it is a quick way to see
if it's useful at all without investing a lot of work into it up front.
On November 10, 2003 10:18 pm, Ferenc Wagner wrote:
> I am making slow progress with this thing. It grew sort of
> usable: can be cross compiled and run to produce sensible
> output (tested on XP only). Present questions:
Looks good, but why did you change it from a cui to a gui?
I guess it's fi
Hi folks,
I've just checked and we're in Top 30 downloads over the last
7 days at SourceForge. More exactly, we're 28th most downloaded
project, with over 2 downloads. Not bad.
We'll need over 3 d/l for Top 20, and over 5 for Top 10.
We'll get there sooner or later. :)
--
Dimi.
On November 11, 2003 05:53 am, Ferenc Wagner wrote:
> Sounds good enough. The question was about the Makefile,
> though. I don't know the build system, unfortunately, so I
> don't even know if it has the necessary basis for this.
It has no basis for it, I guess we'll just need to create
differen
On November 12, 2003 08:30 am, Rein Klazes wrote:
> | if (lpSubItem)
> | {
> | SUBITEM_INFO *lpSubItem = LISTVIEW_GetSubItemPtr(hdpaSubItems,
> | lpLVItem->iSubItem); pItemHdr = lpSubItem ? &lpSubItem->hdr :
> | &callbackHdr;
> |+ if(!lpSubItem) lpLVItem->iSubItem = 0;
> |
On November 15, 2003 09:43 am, Rein Klazes wrote:
OK, this looks good, but 2 small nits:
> - dispInfo.item.iSubItem = lpLVItem->iSubItem;
> + dispInfo.item.iSubItem = isubitem;
I'm not sure if we have to use the original one here or not.
We should add a test for this mess as
On November 17, 2003 07:33 am, Huw D M Davies wrote:
> -LISTBOX_RepaintItem( hwnd, descr, i, ODA_SELECT );
> +if (!IS_OWNERDRAW(descr))
> +LISTBOX_RepaintItem( hwnd, descr, i, ODA_SELECT );
> +else
> +LISTBOX_InvalidateItemRect(hwn
On November 17, 2003 10:16 am, Huw D M Davies wrote:
> +if (LISTBOX_GetItemRect( descr, index, &rect ) == 1)
OK, I very sorry to nick pick so much, but this test is not
only strange in C, but it's a bit dangerous as well, since
in the future LISTBOX_GetItemRect may return something >1
for TRUE
On November 17, 2003 10:47 am, Huw D M Davies wrote:
> I guess that's because there are several other calls to
> LISTBOX_GetItemRect that have the same syntax. Note that
> LISTBOX_GetItemRect can return -1 on error.
Of course, my bad, I've commented without actually checking out
the code. Please
On November 17, 2003 10:53 pm, Tom wrote:
> - loader, but no committed on loader..
Yes, I've just removed loader from the list, as it will
not go away...
--
Dimi.
On November 18, 2003 03:01 am, Lionel Ulmer wrote:
> Imagine the nightmare if all the people asking for Kazaa / HalfLife /
> CounterStrike support on #WineHQ started sending mails to this list ?
Maybe we should have these working and avoid the questions altogether
--
Dimi.
On November 18, 2003 10:37 am, Robert Shearman wrote:
> My MSDN docs don't say anything about them being deprecated or
> absent from comctl32 v6. Where did you find this out from?
I remember seeing the same thing as well: FlatSB are no longer
supported in comctl32 v6. I wish I could point you to t
On November 20, 2003 04:33 pm, Huw D M Davies wrote:
> All of these are unnecessary afaics. glyphList gets alloc'ed in
> GlyphListInit and the two glyph_sent's are alloc'ed in
> T{1|42}_download_header
Thank you, I dropped them from my tree. Alexandre, please
ignore that patch.
--
Dimi.
On November 20, 2003 07:08 pm, Steven Edwards wrote:
> I think HeapReAlloc problem exists in the listbox control. We have a
> patch in ReactOS CVS for it but I dont have time to try and merge it.
Nope, I don't think there are. I've just reviewed the code, and
AFAICS it's just fine. It's been fixed
On November 20, 2003 07:17 pm, Alexandre Julliard wrote:
> Get rid of a bunch of TSX functions.
Yay! Getting rid of the TSX functions seems to be within our
reach now. I hope this is the plan, right? :)
--
Dimi.
On November 20, 2003 11:51 am, Dmitry Timoshkov wrote:
> I don't think it's in their interests to provide an exhaustive list.
Why not?
--
Dimi.
On November 20, 2003 11:30 am, Gerhard W. Gruber wrote:
> Fast application launcher - http://sourceforge.net/projects/launchmenu
BTW Gerhard, is this one building as a Winelib app? If so, does it do it
out of the box?
--
Dimi.
On November 20, 2003 03:33 pm, Gerhard W. Gruber wrote:
> When I download newsgroup articles and I selecte any article in any
> newsgroup, then right-click and choose Index from the context menu, Agent
> crashes. This works under Windows, so this is a Wine problem.
A backtrace would be good, so we
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
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
*
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.
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
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
>
On November 21, 2003 12:16 pm, Ferenc Wagner wrote:
> I would be grateful for a review.
OK,
One more time, this round with a patch incorporating
most of my suggestions. What it does:
-- better integration in the build system
-- supports out of tree builds
-- cleans up file when winetests
501 - 600 of 1008 matches
Mail list logo
