Move GDI handles to the large heap
I'm not sure if this is what Alexandre had in
mind, but here it goes...
... I just realized that some things may break.
In particular, what do we do with
windows/syscolor.c:SYSCOLOR_MakeObjectSystem()
Index: dlls/gdi/gdiobj.c
===
RCS file: /var/cvs/wine/dlls/gdi/gdiobj.c,v
retrieving revision 1.12
diff -u -p -r1.12 gdiobj.c
--- dlls/gdi/gdiobj.c 18 May 2005 09:50:43 - 1.12
+++ dlls/gdi/gdiobj.c 19 May 2005 15:43:31 -
@@ -76,8 +76,6 @@ static CRITICAL_SECTION_DEBUG critsect_d
};
static SYSLEVEL GDI_level = { { critsect_debug, -1, 0, 0, 0, 0 }, 3 };
-static WORD GDI_HeapSel;
-
inline static BOOL get_bool(char *buffer)
{
return (buffer[0] == 'y' || buffer[0] == 'Y' ||
@@ -602,7 +600,6 @@ inline static void dec_ref_count( HGDIOB
*/
BOOL GDI_Init(void)
{
-HINSTANCE16 instance;
HKEY hkey;
GDIOBJHDR *ptr;
LOGFONTW default_gui_font;
@@ -612,9 +609,6 @@ BOOL GDI_Init(void)
if (RegOpenKeyA(HKEY_LOCAL_MACHINE,
Software\\Wine\\Wine\\Config\\Tweak.Fonts, hkey))
hkey = 0;
-/* create GDI heap */
-if ((instance = LoadLibrary16( GDI.EXE )) = 32) GDI_HeapSel = instance
| 7;
-
/* create stock objects */
stock_objects[WHITE_BRUSH] = CreateBrushIndirect( WhiteBrush );
stock_objects[LTGRAY_BRUSH] = CreateBrushIndirect( LtGrayBrush );
@@ -710,34 +704,9 @@ inline static GDIOBJHDR *alloc_large_hea
void *GDI_AllocObject( WORD size, WORD magic, HGDIOBJ *handle, const struct
gdi_obj_funcs *funcs )
{
GDIOBJHDR *obj = NULL;
-HLOCAL16 hlocal;
_EnterSysLevel( GDI_level );
-switch(magic)
-{
-case PEN_MAGIC:
-case BRUSH_MAGIC:
-if (GDI_HeapSel)
-{
-STACK16FRAME* stack16 =
MapSL((SEGPTR)NtCurrentTeb()-WOW32Reserved);
-HANDLE16 oldDS = stack16-ds;
-
-stack16-ds = GDI_HeapSel;
-if ((hlocal = LocalAlloc16( LMEM_MOVEABLE, size )))
-{
-assert( hlocal 2 );
-obj = MapSL(LocalLock16( hlocal ));
-*handle = (HGDIOBJ)(ULONG_PTR)hlocal;
-}
-stack16-ds = oldDS;
-if (!hlocal) goto error;
-break;
-}
-/* fall through */
-default:
-if (!(obj = alloc_large_heap( size, handle ))) goto error;
-break;
-}
+if (!(obj = alloc_large_heap( size, handle ))) goto error;
obj-wMagic = magic|OBJECT_NOSYSTEM;
obj-dwCount = 0;
@@ -762,34 +731,16 @@ error:
*/
void *GDI_ReallocObject( WORD size, HGDIOBJ handle, void *object )
{
-HGDIOBJ new_handle;
void *new_ptr = NULL;
+int i;
-if ((UINT_PTR)handle 2) /* GDI heap handle */
-{
-STACK16FRAME* stack16 = MapSL((SEGPTR)NtCurrentTeb()-WOW32Reserved);
-HANDLE16 oldDS = stack16-ds;
-HLOCAL16 h = LOWORD(handle);
-
-stack16-ds = GDI_HeapSel;
-LocalUnlock16( h );
-if ((new_handle = (HGDIOBJ)(ULONG_PTR)LocalReAlloc16( h, size,
LMEM_MOVEABLE )))
-{
-assert( new_handle == handle ); /* moveable handle cannot change
*/
-new_ptr = MapSL(LocalLock16( h ));
-}
-stack16-ds = oldDS;
-}
-else
+i = ((ULONG_PTR)handle 2) - FIRST_LARGE_HANDLE;
+if (i = 0 i MAX_LARGE_HANDLES large_handles[i])
{
-int i = ((ULONG_PTR)handle 2) - FIRST_LARGE_HANDLE;
-if (i = 0 i MAX_LARGE_HANDLES large_handles[i])
-{
-new_ptr = HeapReAlloc( GetProcessHeap(), 0, large_handles[i], size
);
-if (new_ptr) large_handles[i] = new_ptr;
-}
-else ERR( Invalid handle %p\n, handle );
+new_ptr = HeapReAlloc( GetProcessHeap(), 0, large_handles[i], size );
+if (new_ptr) large_handles[i] = new_ptr;
}
+else ERR( Invalid handle %p\n, handle );
if (!new_ptr)
{
TRACE((%p): leave %ld\n, handle, GDI_level.crst.RecursionCount);
@@ -805,30 +756,17 @@ void *GDI_ReallocObject( WORD size, HGDI
BOOL GDI_FreeObject( HGDIOBJ handle, void *ptr )
{
GDIOBJHDR *object = ptr;
+int i;
object-wMagic = 0; /* Mark it as invalid */
object-funcs = NULL;
-if ((UINT_PTR)handle 2) /* GDI heap handle */
+i = ((ULONG_PTR)handle 2) - FIRST_LARGE_HANDLE;
+if (i = 0 i MAX_LARGE_HANDLES large_handles[i])
{
-STACK16FRAME* stack16 = MapSL((SEGPTR)NtCurrentTeb()-WOW32Reserved);
-HANDLE16 oldDS = stack16-ds;
-HLOCAL16 h = LOWORD(handle);
-
-stack16-ds = GDI_HeapSel;
-LocalUnlock16( h );
-LocalFree16( h );
-stack16-ds = oldDS;
-}
-else /* large heap handle */
-{
-int i = ((ULONG_PTR)handle 2) - FIRST_LARGE_HANDLE;
-if (i = 0 i MAX_LARGE_HANDLES large_handles[i])
-{
-HeapFree( GetProcessHeap(), 0, large_handles[i] );
-large_handles[i] = NULL;
-}
-else ERR(
Re: Wiki stuff
On Mon, 2005-05-09 at 09:36 +0200, [EMAIL PROTECTED] wrote: Could you post a link to a page that display this issue? I just looked at http://wiki.winehq.org/InstallShield and it was fine on opera 8 but I did not have time to check to see how you had defined pre Not really, I've told you that the display problem (that is, you were getting proportional fonts) occurred when the .css for pre contained a line like so: font-family: courier, monospace; I've commented that out, and now things work just fine. Take a look at: http://wiki.winehq.org/moin/winehq/css/common.css -- Dimi.
Re: Wiki stuff
On Sun, 2005-05-08 at 13:12 +0100, Mike Hearn wrote:
More Wiki stuff: for some reason on my browser at least pre sections
aren't showing as a monospace font which makes embedded code hard to read.
Is this some CSS thing? Firefox renders text/plain files as monospace OK
so it's not my fonts.
Yes, this is indeed rather strange. We used to have this:
pre {
padding: 0.5em;
font-family: courier, monospace;
For whatever reason, asking for courier/monospace for pre causes the
browser to display proportional fonts (at least for the two of us).
A fontconfig bug? Anyway, if I comment it out and let the browser use
its default font, it works.
Explanations about why this happens are most welcomed.
--
Dimi.
Re: Wine Wiki Status
On Fri, May 06, 2005 at 12:12:01PM +0100, Mike Hearn wrote: The slashdotting has passed, I doubt it'll be a problem again. I should have known better than to directly link to it from the story. D'oh! Don't worry, it wasn't a big deal, I think it was OK to post to ./ And hey, it was a good server test, we survived just fine! :) I wanted to require that you login to edit anyway, it was so easy to forget that I even forgot a few times. Do people want to go back to the old way, and allow even not logged in people edit? -- Dimi.
Re: unix filenames in notepad
On Fri, May 06, 2005 at 02:12:22AM -0500, James Hawkins wrote: That's the beauty of it! wineprefixcreate sets z: to point to / automatically. Of course the user can always change what z: points to, but / is the default location. James, if an application informs us somehow (TBD) that they can handle Unix paths, there's no reason to force the silly drive letters on Unix users. Ideally we would even hide the drive letter combo box in the file dialogs. -- Dimi.
Re: InstallShield status page on the wiki
On Thu, May 05, 2005 at 12:35:46PM +0100, Mike Hearn wrote: Dimi, the p tags don't seem to create any bottom padding like they would normally so all the text seems squashed together even if they have newlines between them. Can this stylesheet problem be fixed? Done. I'll make the code and .css available shortly via CVS, so people can send improvements too. If there's anything that you'd like changed on the wiki, just send an email to this list, or add a note to my home page on the wiki: http://wiki.winehq.org/DimiPaun -- Dimi.
Re: InstallShield status page on the wiki
On Thu, May 05, 2005 at 01:59:15PM +0200, Boaz Harrosh wrote: Dimi while you are at it: I used : 1. FCKEditor http://fckeditor.sourceforge.net or 2. HTMLArea http://drupal.org/project/htmlarea. Last time I installed them on My Linux-Apache at home it took me 10 minutes. Do have a look it makes Wiki life go to a different level We're using MoinMoin 1.3.4. I'm not sure it works with those editors, can you point me to docs on how to integrate them? I don't mind the regular wiki markup, but if people prefer the above editors instead, I'm happy to include them as long as it can be done cleanly and they can be a personal preference (I don't want to force them on everybody). -- Dimi.
Re: winecfg: Add wine configuration tab
On Thu, May 05, 2005 at 12:50:50AM -0500, James Hawkins wrote: [1] http://winehq.org/site/status_options I'm afraid this page is a bit out of date. It needs lots of love, and I think it would be a worthwhile project to update it. -- Dimi.
Re: winecfg: Add wine configuration tab
On Thu, May 05, 2005 at 12:50:50AM -0500, James Hawkins wrote: I used the options specified for [wine] in the Wine Options Status page [1] to create a new wine options tab for winecfg. I think we intentionally omitted such a page before. The thinking is that these are really low-level settings that normal users shouldn't touch. Those who *need* to for whatever strange reason can use regedit to do so. This is why it is important to have an up-to-date status_options page to begin with, so that people at least have a chance of knowing what options are available (for those not accessible via winecfg). -- Dimi.
Wine Wiki Status
A few things: 1. We've been attacked Wed by one or two idiots from Slashdot. They kept replacing the content of the front page with some silly Balmer images :) Not a big deal, since MoinMoin makes it a snap to revert to an older version. However, this episode forced me to at least require that you sign up before you can edit a page. This is probably a good idea anyway, I hope people agree. 2. I've placed the modifications to the code on the Wine CVS repository at SourceForge in the 'wiki' module. Please feel free to check it out and send in patches (sending them to [EMAIL PROTECTED] with a subject prefix of 'Wiki:' is fine, or directly to me if you prefer). 3. Mike is right, the namespacing stuff if not a good idea. I'll try to get rid of it, I'm going to try to rename the page, but first I have to enable the feature. If not, I'll just simply recreate them. As always, you comments, suggestions and complaints are most welcome. -- Dimi.
Re: Commercial support
On Wed, May 04, 2005 at 07:33:53AM -0400, Tom Wickline wrote: 1) a token monetary fee of around $10,000 per year. I was thinking more like $100, to help out CW with hosting. At 10K most companies will shy away, and we don't want that. We want more people there, not fewer. This is not money for advertising. We can drop it altogether AFAIAC, I don't think it's important. On the other hand, if CW want a bit of help with the server, I think it's fair that we all chip in. -- Dimi.
Re: Commercial support
On Tue, May 03, 2005 at 03:22:34PM -0500, Jeremy White wrote: site should be open to anyone that requests to be listed there, and that it should be in alphabetical order. Name recognition matters. In fact, for Open Source companies it may be the only thing they have to work with. As such, I think the order is important. I'm afraid that going the alphabetical order way we're sending the wrong message: Don't bother sending patches in, just choose a company name that sorts high. And ultimately, this is bad for Wine. Also, this seems to be blown out of proportion: none of the possible candidates have a problem with a ranked list. In fact, I think 3 out of 4 supported the idea :) Why not just do that? -- Dimi.
Re: Commercial support
On Tue, May 03, 2005 at 11:33:36AM +0200, David Gümbel wrote: So I'd suggest listing anyone who can prove he has contributed to Wine in whatever way - making a donation, having contributed code, whatever - , and let the customers decide whom to select for their particular problem. Yes, I think being inclusive is better. However, I also think that we need to pick the rules carefully so we don't set up a bad precedent when half the world will be using Wine :). So here is what I propose: 1. The list should be capped to n entries (n=50, 100?) 2. It should be kept up to date, and refreshed at least yearly 3. Any list has an order by definition, this one should be ranked by how much each company benefits the project. Notes: - Rule (1) doesn't mean much now, but it may in the future if we get flooded with requests for listing - Rule (2) seems everyone agrees with. I suggest a token monetary fee that should go towards hosting the WineHQ site. - Rule (3) is the most tricky of all. But please realise that we should be talking from the project's perspective here (we are talking about WineHQ site), not our own commercial perspective. It is fundamental that things are fair to encourage future cooperation, and that is the one and most important thing from the project POV. And yes, code contributions are not the only thing. Regardless, it is not difficult to rank. Here is what I suggest: * company makes a request for linking by submitting a patch to the appropriate page on wine-patches. If they don't know how to do that, they may ask someone for help, but the patch should be posted on the list before it can go in. * if there are any disagreements as to the proposed order, we can ask for a quick vote on the list. Each vote will include the rank the voter gives to the listings. An average of the vote should determine the rank. Please check out Wisdom of Crowds why this works very well. In any event, I don't think there is that much of a problem to come up with a ranking at the time being. -- Dimi.
Re: Benchmarking Wine againt XP Part 2
On Sun, May 01, 2005 at 01:31:59PM -0400, Tom Wickline wrote: I have run Pov-Ray in the past if anyone is interested in this bench ill re-install it and run it again. http://www.povray.org/ If you can do it, it may prove useful. -- Dimi.
Re: Benchmarking Wine againt XP Part 2
On Fri, Apr 29, 2005 at 02:13:57PM -0400, Tom Wickline wrote: This is part two of the results. These things should be nicely formatted and posted on the Wiki: wiki.winehq.org This way we can keep track of such results, see how we (hopefully) improve in time. -- Dimi.
Re: PATCH: gcc4 alias fixes
On Sun, Apr 24, 2005 at 10:02:47PM +0200, Marcus Meissner wrote: Hi, This is the patch I use for gcc4.0 here. I am not really sure why this aliasing was introduced, but it will not work this way anymore. I still don't understand why it doesn't work. It was introduced because using macros it not always acceptable. Some source uses these functions in ways that break if they are defined as macros. Defining them as inline functions work, but we can't do so for varargs, in which case we used aliases. What was the reason to break them, and why they don't work? They are aliasing to things that _are_ defined, so I'm not sure what is going on there. -- Dimi.
Re: Make VIRTUAL_SetFaultHandler an internal function (take 3)
On Tue, Apr 19, 2005 at 01:13:12PM +0200, Alexandre Julliard wrote:
You can't hold the critsection when adding the handler since this will
grab the vectored_handlers critsection, and thus acquire the sections
in the reverse order of what happens when the handler is called.
Good point, I haven't even considered it. Thanks for catching this
nasty. As for the list, I'm not sure it's worth sorting, that optimizes
the slow path anyway. Maybe it's more advantageous to keep the
most recently used DIB at the front of the list. If this is a problem,
we can have a more complicated struture to do a more clever search,
but this is a different patch.
ChangeLog
Use vectored exceptions to get rid of VIRTUAL_SetFaultHandler().
Index: dlls/ntdll/ntdll.spec
===
RCS file: /var/cvs/wine/dlls/ntdll/ntdll.spec,v
retrieving revision 1.177
diff -u -p -r1.177 ntdll.spec
--- dlls/ntdll/ntdll.spec 16 Apr 2005 11:19:27 - 1.177
+++ dlls/ntdll/ntdll.spec 18 Apr 2005 11:42:07 -
@@ -1036,4 +1036,3 @@
@ cdecl MODULE_DllThreadAttach(ptr)
@ cdecl MODULE_GetLoadOrderW(ptr wstr wstr)
@ cdecl VERSION_Init(wstr)
-@ cdecl VIRTUAL_SetFaultHandler(ptr ptr ptr)
Index: dlls/ntdll/virtual.c
===
RCS file: /var/cvs/wine/dlls/ntdll/virtual.c,v
retrieving revision 1.46
diff -u -p -r1.46 virtual.c
--- dlls/ntdll/virtual.c22 Feb 2005 19:33:50 - 1.46
+++ dlls/ntdll/virtual.c17 Apr 2005 04:20:14 -
@@ -1098,25 +1104,6 @@ void virtual_init(void)
/***
- * VIRTUAL_SetFaultHandler
- */
-BOOL VIRTUAL_SetFaultHandler( LPCVOID addr, HANDLERPROC proc, LPVOID arg )
-{
-FILE_VIEW *view;
-BOOL ret = FALSE;
-
-RtlEnterCriticalSection( csVirtual );
-if ((view = VIRTUAL_FindView( addr )))
-{
-view-handlerProc = proc;
-view-handlerArg = arg;
-ret = TRUE;
-}
-RtlLeaveCriticalSection( csVirtual );
-return ret;
-}
-
-/***
* VIRTUAL_HandleFault
*/
DWORD VIRTUAL_HandleFault( LPCVOID addr )
Index: dlls/x11drv/dib.c
===
RCS file: /var/cvs/wine/dlls/x11drv/dib.c,v
retrieving revision 1.35
diff -u -p -r1.35 dib.c
--- dlls/x11drv/dib.c 14 Apr 2005 12:48:31 - 1.35
+++ dlls/x11drv/dib.c 19 Apr 2005 12:26:23 -
@@ -38,11 +38,25 @@
#include winbase.h
#include wingdi.h
#include x11drv.h
+#include excpt.h
#include wine/debug.h
WINE_DEFAULT_DEBUG_CHANNEL(bitmap);
WINE_DECLARE_DEBUG_CHANNEL(x11drv);
+static struct list dibs_list = LIST_INIT(dibs_list);
+
+static CRITICAL_SECTION dibs_cs;
+static CRITICAL_SECTION_DEBUG dibs_cs_debug =
+{
+0, 0, dibs_cs,
+{ dibs_cs_debug.ProcessLocksList, dibs_cs_debug.ProcessLocksList },
+ 0, 0, { 0, (DWORD)(__FILE__ : dibs_cs) }
+};
+static CRITICAL_SECTION dibs_cs = { dibs_cs_debug, -1, 0, 0, 0, 0 };
+
+PVOID dibs_handler = 0;
+
static int ximageDepthTable[32];
/* This structure holds the arguments for DIB_SetImageBits() */
@@ -4268,22 +4282,43 @@ static void X11DRV_DIB_DoUpdateDIBSectio
/***
* X11DRV_DIB_FaultHandler
*/
-static BOOL X11DRV_DIB_FaultHandler( LPVOID res, LPCVOID addr )
+static LONG CALLBACK X11DRV_DIB_FaultHandler( PEXCEPTION_POINTERS ep )
{
- X_PHYSBITMAP *physBitmap = res;
- INT state = X11DRV_DIB_Lock( physBitmap, DIB_Status_None, FALSE );
+X_PHYSBITMAP *physBitmap = NULL;
+BOOL found = FALSE;
+const BYTE *addr;
+struct list *ptr;
- if (state != DIB_Status_InSync) {
-/* no way to tell whether app needs read or write yet,
- * try read first */
-X11DRV_DIB_Coerce( physBitmap, DIB_Status_InSync, FALSE );
- } else {
-/* hm, apparently the app must have write access */
-X11DRV_DIB_Coerce( physBitmap, DIB_Status_AppMod, FALSE );
- }
- X11DRV_DIB_Unlock( physBitmap, TRUE );
+if (ep-ExceptionRecord-ExceptionCode != EXCEPTION_ACCESS_VIOLATION)
+return EXCEPTION_CONTINUE_SEARCH;
+
+addr = (const BYTE*)ep-ExceptionRecord-ExceptionInformation[1];
+
+EnterCriticalSection(dibs_cs);
+LIST_FOR_EACH( ptr, dibs_list )
+{
+physBitmap = LIST_ENTRY( ptr, X_PHYSBITMAP, entry );
+if ((physBitmap-base = addr) (addr physBitmap-base +
physBitmap-size))
+{
+found = TRUE;
+break;
+}
+}
+LeaveCriticalSection(dibs_cs);
+
+if (!found) return EXCEPTION_CONTINUE_SEARCH;
+
+X11DRV_DIB_Lock( physBitmap, DIB_Status_None, FALSE );
+if (ep-ExceptionRecord-ExceptionInformation[0]) {
+/* the app tried to write the DIB bits */
+X11DRV_DIB_Coerce( physBitmap, DIB_Status_AppMod, FALSE );
+} else {
+/* the
Re: Make VIRTUAL_SetFaultHandler an internal function (take 3)
On Tue, Apr 19, 2005 at 08:37:30PM +0200, Alexandre Julliard wrote: Actually you have the same problem with the GDI lock, this is going to be more tricky to solve... Duh! One way to do it is to not hold the lock while we call the handler. Which I think we need to do anyway, as app handlers are not under our control :) But to do so, we need to see what semantics we must have for the loop calling the handlers. If we drop the lock, the list can be changed while we iterate through it. A simple solution would be to detect such a change, and if it occurs, restart from the beginning? But I'm not sure that's going to cut it :) Or notice that we are handling a fault in Add/Remove and simply store the handler in another list that will be processed by the main handler after it has finished processing the current fault. -- Dimi.
Re: Make VIRTUAL_SetFaultHandler an internal function
On Mon, Apr 18, 2005 at 01:06:23PM +0200, Alexandre Julliard wrote:
Sure, the general idea is fine. You actually don't need a mem_area
structure at all, you can store that directly in the phys bitmap. Also
it would be nice to only set the handler when a DIB is allocated, not
at startup.
Right, I realized that after sending the email about making the data
field a pointer to physBitmap. Compiles, but not tested, as I don't
have a DIB using app.
ChangeLog
Remove the VIRTUAL_SetFaultHandler(), use vectored exceptions instead.
Index: dlls/ntdll/ntdll.spec
===
RCS file: /var/cvs/wine/dlls/ntdll/ntdll.spec,v
retrieving revision 1.177
diff -u -p -r1.177 ntdll.spec
--- dlls/ntdll/ntdll.spec 16 Apr 2005 11:19:27 - 1.177
+++ dlls/ntdll/ntdll.spec 18 Apr 2005 11:42:07 -
@@ -1036,4 +1036,3 @@
@ cdecl MODULE_DllThreadAttach(ptr)
@ cdecl MODULE_GetLoadOrderW(ptr wstr wstr)
@ cdecl VERSION_Init(wstr)
-@ cdecl VIRTUAL_SetFaultHandler(ptr ptr ptr)
Index: dlls/ntdll/virtual.c
===
RCS file: /var/cvs/wine/dlls/ntdll/virtual.c,v
retrieving revision 1.46
diff -u -p -r1.46 virtual.c
--- dlls/ntdll/virtual.c22 Feb 2005 19:33:50 - 1.46
+++ dlls/ntdll/virtual.c17 Apr 2005 04:20:14 -
@@ -1098,25 +1104,6 @@ void virtual_init(void)
/***
- * VIRTUAL_SetFaultHandler
- */
-BOOL VIRTUAL_SetFaultHandler( LPCVOID addr, HANDLERPROC proc, LPVOID arg )
-{
-FILE_VIEW *view;
-BOOL ret = FALSE;
-
-RtlEnterCriticalSection( csVirtual );
-if ((view = VIRTUAL_FindView( addr )))
-{
-view-handlerProc = proc;
-view-handlerArg = arg;
-ret = TRUE;
-}
-RtlLeaveCriticalSection( csVirtual );
-return ret;
-}
-
-/***
* VIRTUAL_HandleFault
*/
DWORD VIRTUAL_HandleFault( LPCVOID addr )
Index: dlls/x11drv/dib.c
===
RCS file: /var/cvs/wine/dlls/x11drv/dib.c,v
retrieving revision 1.35
diff -u -p -r1.35 dib.c
--- dlls/x11drv/dib.c 14 Apr 2005 12:48:31 - 1.35
+++ dlls/x11drv/dib.c 18 Apr 2005 12:14:34 -
@@ -38,11 +38,25 @@
#include winbase.h
#include wingdi.h
#include x11drv.h
+#include excpt.h
#include wine/debug.h
WINE_DEFAULT_DEBUG_CHANNEL(bitmap);
WINE_DECLARE_DEBUG_CHANNEL(x11drv);
+static struct list dibs_list = LIST_INIT(dibs_list);
+
+static CRITICAL_SECTION dibs_cs;
+static CRITICAL_SECTION_DEBUG dibs_cs_debug =
+{
+0, 0, dibs_cs,
+{ dibs_cs_debug.ProcessLocksList, dibs_cs_debug.ProcessLocksList },
+ 0, 0, { 0, (DWORD)(__FILE__ : dibs_cs) }
+};
+static CRITICAL_SECTION dibs_cs = { dibs_cs_debug, -1, 0, 0, 0, 0 };
+
+PVOID dibs_handler = 0;
+
static int ximageDepthTable[32];
/* This structure holds the arguments for DIB_SetImageBits() */
@@ -4268,22 +4282,43 @@ static void X11DRV_DIB_DoUpdateDIBSectio
/***
* X11DRV_DIB_FaultHandler
*/
-static BOOL X11DRV_DIB_FaultHandler( LPVOID res, LPCVOID addr )
+static LONG CALLBACK X11DRV_DIB_FaultHandler( PEXCEPTION_POINTERS ep )
{
- X_PHYSBITMAP *physBitmap = res;
- INT state = X11DRV_DIB_Lock( physBitmap, DIB_Status_None, FALSE );
+X_PHYSBITMAP *physBitmap = NULL;
+BOOL found = FALSE;
+struct list *ptr;
+INT state;
+
+if (ep-ExceptionRecord-ExceptionCode != EXCEPTION_ACCESS_VIOLATION)
+return EXCEPTION_CONTINUE_SEARCH;
+
+EnterCriticalSection(dibs_cs);
+LIST_FOR_EACH( ptr, dibs_list )
+{
+physBitmap = LIST_ENTRY( ptr, X_PHYSBITMAP, entry );
+if (physBitmap-base ep-ExceptionRecord-ExceptionAddress) break;
+if ((const char*)ep-ExceptionRecord-ExceptionAddress
+(const char*)physBitmap-base + physBitmap-size)
+{
+found = TRUE;
+break;
+}
+}
+LeaveCriticalSection(dibs_cs);
- if (state != DIB_Status_InSync) {
-/* no way to tell whether app needs read or write yet,
- * try read first */
-X11DRV_DIB_Coerce( physBitmap, DIB_Status_InSync, FALSE );
- } else {
-/* hm, apparently the app must have write access */
-X11DRV_DIB_Coerce( physBitmap, DIB_Status_AppMod, FALSE );
- }
- X11DRV_DIB_Unlock( physBitmap, TRUE );
+if (!found) return EXCEPTION_CONTINUE_SEARCH;
- return TRUE;
+state = X11DRV_DIB_Lock( physBitmap, DIB_Status_None, FALSE );
+if (state != DIB_Status_InSync) {
+/* no way to tell whether app needs read or write yet, try read first
*/
+X11DRV_DIB_Coerce( physBitmap, DIB_Status_InSync, FALSE );
+} else {
+/* hm, apparently the app must have write access */
+X11DRV_DIB_Coerce( physBitmap, DIB_Status_AppMod, FALSE );
+
Re: Make VIRTUAL_SetFaultHandler an internal function (take 3)
On Mon, Apr 18, 2005 at 10:46:10PM +0900, Dmitry Timoshkov wrote:
Here is a largely simplified source ripped from one of my very old projects
which loads a TGA file and shows it using a DIB section. A sample TGA file
is included.
Thank you Dmitry. It didn't test the fault handler directly, but it was
easy to modify it to do so.
Now with working code... (found one small, but essential bug: the
ExceptionAddress is the address of the code, not of the data, that's
in ExceptionInformation. Oh well :)).
ChangeLog
Use vectored exception handling to get rid of VIRTUAL_SetFaultHandler().
Index: dlls/ntdll/ntdll.spec
===
RCS file: /var/cvs/wine/dlls/ntdll/ntdll.spec,v
retrieving revision 1.177
diff -u -p -r1.177 ntdll.spec
--- dlls/ntdll/ntdll.spec 16 Apr 2005 11:19:27 - 1.177
+++ dlls/ntdll/ntdll.spec 18 Apr 2005 11:42:07 -
@@ -1036,4 +1036,3 @@
@ cdecl MODULE_DllThreadAttach(ptr)
@ cdecl MODULE_GetLoadOrderW(ptr wstr wstr)
@ cdecl VERSION_Init(wstr)
-@ cdecl VIRTUAL_SetFaultHandler(ptr ptr ptr)
Index: dlls/ntdll/virtual.c
===
RCS file: /var/cvs/wine/dlls/ntdll/virtual.c,v
retrieving revision 1.46
diff -u -p -r1.46 virtual.c
--- dlls/ntdll/virtual.c22 Feb 2005 19:33:50 - 1.46
+++ dlls/ntdll/virtual.c17 Apr 2005 04:20:14 -
@@ -1098,25 +1104,6 @@ void virtual_init(void)
/***
- * VIRTUAL_SetFaultHandler
- */
-BOOL VIRTUAL_SetFaultHandler( LPCVOID addr, HANDLERPROC proc, LPVOID arg )
-{
-FILE_VIEW *view;
-BOOL ret = FALSE;
-
-RtlEnterCriticalSection( csVirtual );
-if ((view = VIRTUAL_FindView( addr )))
-{
-view-handlerProc = proc;
-view-handlerArg = arg;
-ret = TRUE;
-}
-RtlLeaveCriticalSection( csVirtual );
-return ret;
-}
-
-/***
* VIRTUAL_HandleFault
*/
DWORD VIRTUAL_HandleFault( LPCVOID addr )
Index: dlls/x11drv/dib.c
===
RCS file: /var/cvs/wine/dlls/x11drv/dib.c,v
retrieving revision 1.35
diff -u -p -r1.35 dib.c
--- dlls/x11drv/dib.c 14 Apr 2005 12:48:31 - 1.35
+++ dlls/x11drv/dib.c 19 Apr 2005 01:45:59 -
@@ -38,11 +38,25 @@
#include winbase.h
#include wingdi.h
#include x11drv.h
+#include excpt.h
#include wine/debug.h
WINE_DEFAULT_DEBUG_CHANNEL(bitmap);
WINE_DECLARE_DEBUG_CHANNEL(x11drv);
+static struct list dibs_list = LIST_INIT(dibs_list);
+
+static CRITICAL_SECTION dibs_cs;
+static CRITICAL_SECTION_DEBUG dibs_cs_debug =
+{
+0, 0, dibs_cs,
+{ dibs_cs_debug.ProcessLocksList, dibs_cs_debug.ProcessLocksList },
+ 0, 0, { 0, (DWORD)(__FILE__ : dibs_cs) }
+};
+static CRITICAL_SECTION dibs_cs = { dibs_cs_debug, -1, 0, 0, 0, 0 };
+
+PVOID dibs_handler = 0;
+
static int ximageDepthTable[32];
/* This structure holds the arguments for DIB_SetImageBits() */
@@ -4268,22 +4282,45 @@ static void X11DRV_DIB_DoUpdateDIBSectio
/***
* X11DRV_DIB_FaultHandler
*/
-static BOOL X11DRV_DIB_FaultHandler( LPVOID res, LPCVOID addr )
+static LONG CALLBACK X11DRV_DIB_FaultHandler( PEXCEPTION_POINTERS ep )
{
- X_PHYSBITMAP *physBitmap = res;
- INT state = X11DRV_DIB_Lock( physBitmap, DIB_Status_None, FALSE );
+X_PHYSBITMAP *physBitmap = NULL;
+BOOL found = FALSE;
+const BYTE *addr;
+struct list *ptr;
+INT state;
- if (state != DIB_Status_InSync) {
-/* no way to tell whether app needs read or write yet,
- * try read first */
-X11DRV_DIB_Coerce( physBitmap, DIB_Status_InSync, FALSE );
- } else {
-/* hm, apparently the app must have write access */
-X11DRV_DIB_Coerce( physBitmap, DIB_Status_AppMod, FALSE );
- }
- X11DRV_DIB_Unlock( physBitmap, TRUE );
+if (ep-ExceptionRecord-ExceptionCode != EXCEPTION_ACCESS_VIOLATION)
+return EXCEPTION_CONTINUE_SEARCH;
+
+addr = (const BYTE*)ep-ExceptionRecord-ExceptionInformation[1];
+
+EnterCriticalSection(dibs_cs);
+LIST_FOR_EACH( ptr, dibs_list )
+{
+physBitmap = LIST_ENTRY( ptr, X_PHYSBITMAP, entry );
+if (physBitmap-base addr) break;
+if (addr physBitmap-base + physBitmap-size)
+{
+found = TRUE;
+break;
+}
+}
+LeaveCriticalSection(dibs_cs);
+
+if (!found) return EXCEPTION_CONTINUE_SEARCH;
+
+state = X11DRV_DIB_Lock( physBitmap, DIB_Status_None, FALSE );
+if (state != DIB_Status_InSync) {
+/* no way to tell whether app needs read or write yet, try read first
*/
+X11DRV_DIB_Coerce( physBitmap, DIB_Status_InSync, FALSE );
+} else {
+/* hm, apparently the app must have write access */
+X11DRV_DIB_Coerce(
Re: Make VIRTUAL_SetFaultHandler an internal function
On Sun, Apr 17, 2005 at 08:44:57AM -0500, Rob Shearman wrote:
Why don't you free area here?
Details, details. But if you insist ... :)
Index: dlls/ntdll/ntdll.spec
===
RCS file: /var/cvs/wine/dlls/ntdll/ntdll.spec,v
retrieving revision 1.175
diff -u -p -r1.175 ntdll.spec
--- dlls/ntdll/ntdll.spec 30 Mar 2005 10:22:51 - 1.175
+++ dlls/ntdll/ntdll.spec 17 Apr 2005 04:18:44 -
@@ -1035,4 +1035,3 @@
@ cdecl MODULE_DllThreadAttach(ptr)
@ cdecl MODULE_GetLoadOrderW(ptr wstr wstr)
@ cdecl VERSION_Init(wstr)
-@ cdecl VIRTUAL_SetFaultHandler(ptr ptr ptr)
Index: dlls/ntdll/virtual.c
===
RCS file: /var/cvs/wine/dlls/ntdll/virtual.c,v
retrieving revision 1.46
diff -u -p -r1.46 virtual.c
--- dlls/ntdll/virtual.c22 Feb 2005 19:33:50 - 1.46
+++ dlls/ntdll/virtual.c17 Apr 2005 04:20:14 -
@@ -1098,25 +1104,6 @@ void virtual_init(void)
/***
- * VIRTUAL_SetFaultHandler
- */
-BOOL VIRTUAL_SetFaultHandler( LPCVOID addr, HANDLERPROC proc, LPVOID arg )
-{
-FILE_VIEW *view;
-BOOL ret = FALSE;
-
-RtlEnterCriticalSection( csVirtual );
-if ((view = VIRTUAL_FindView( addr )))
-{
-view-handlerProc = proc;
-view-handlerArg = arg;
-ret = TRUE;
-}
-RtlLeaveCriticalSection( csVirtual );
-return ret;
-}
-
-/***
* VIRTUAL_HandleFault
*/
DWORD VIRTUAL_HandleFault( LPCVOID addr )
Index: dlls/x11drv/dib.c
===
RCS file: /var/cvs/wine/dlls/x11drv/dib.c,v
retrieving revision 1.35
diff -u -p -r1.35 dib.c
--- dlls/x11drv/dib.c 14 Apr 2005 12:48:31 - 1.35
+++ dlls/x11drv/dib.c 17 Apr 2005 15:10:03 -
@@ -38,11 +38,32 @@
#include winbase.h
#include wingdi.h
#include x11drv.h
+#include excpt.h
+#include wine/list.h
#include wine/debug.h
WINE_DEFAULT_DEBUG_CHANNEL(bitmap);
WINE_DECLARE_DEBUG_CHANNEL(x11drv);
+struct mem_area
+{
+struct list entry; /* Entry in global mem area list */
+const void *base;/* Base address */
+UINT size;/* Size in bytes */
+void *data;/* Data associated with this area */
+};
+
+static struct list mem_areas_list = LIST_INIT(mem_areas_list);
+
+static CRITICAL_SECTION csMemAreas;
+static CRITICAL_SECTION_DEBUG csMemAreas_debug =
+{
+0, 0, csMemAreas,
+{ csMemAreas_debug.ProcessLocksList, csMemAreas_debug.ProcessLocksList },
+ 0, 0, { 0, (DWORD)(__FILE__ : csMemAreas) }
+};
+static CRITICAL_SECTION csMemAreas = { csMemAreas_debug, -1, 0, 0, 0, 0 };
+
static int ximageDepthTable[32];
/* This structure holds the arguments for DIB_SetImageBits() */
@@ -88,6 +109,89 @@ static INT X11DRV_DIB_Coerce(X_PHYSBITMA
static INT X11DRV_DIB_Lock(X_PHYSBITMAP *,INT,BOOL);
static void X11DRV_DIB_Unlock(X_PHYSBITMAP *,BOOL);
+/***
+ * mem_area_find
+ *
+ * Find the memory area containing a given address.
+ * The csMemAreas section must be held by caller.
+ *
+ * PARAMS
+ * addr [I] Address
+ *
+ * RETURNS
+ * Success: area
+ * Failure: NULL
+ */
+static struct mem_area *mem_area_find( const void *addr )
+{
+struct list *ptr;
+
+LIST_FOR_EACH( ptr, mem_areas_list )
+{
+struct mem_area *area = LIST_ENTRY( ptr, struct mem_area, entry );
+if (area-base addr) break;
+if ((const char*)addr (const char*)area-base + area-size) return
area;
+}
+return NULL;
+}
+
+/***
+ * mem_area_add
+ *
+ * Adds a memory area to the list.
+ *
+ * PARAMS
+ * base [I] Beginning address of the area
+ * size [I] Size of the area
+ * data [I] Data associated with the area
+ *
+ */
+static struct mem_area *mem_area_add( const void *base, UINT size, void *data )
+{
+struct mem_area *area;
+
+area = HeapAlloc(GetProcessHeap(), 0, sizeof(*area));
+if (!area) return NULL;
+
+area-base = base;
+area-size = size;
+area-data = data;
+
+EnterCriticalSection( csMemAreas );
+list_add_head( mem_areas_list, area-entry );
+LeaveCriticalSection( csMemAreas );
+
+return area;
+}
+
+
+/***
+ * mem_area_del
+ *
+ * Removes a memory area from the list.
+ *
+ * PARAMS
+ * addr [I] Address
+ *
+ * RETURNS
+ * Success: TRUE
+ * Failure: FALSE
+ */
+static BOOL mem_area_del( const void *addr )
+{
+struct mem_area *area;
+
+EnterCriticalSection( csMemAreas );
+area = mem_area_find( addr );
+if (area) list_remove( area-entry );
+
Re: Make VIRTUAL_SetFaultHandler an internal function
On Mon, Apr 18, 2005 at 12:29:07AM +0900, Dmitry Timoshkov wrote:
Dimitrie O. Paun [EMAIL PROTECTED] wrote:
+struct mem_area
+{
+struct list entry; /* Entry in global mem area list */
+const void *base;/* Base address */
+UINT size;/* Size in bytes */
+void *data;/* Data associated with this area */
+};
One more nitpick: it's better to change the size type to SIZE_T from UINT
to allow 64-bit size memory allocations on (future) Win64.
Yeah, and on second thought even this mem_area is too general because
they are build specifically for DIBs. I should rename them dib_area,
and instead of void *data, I should have X_PHYSBITMAP *physBitmap.
But I'd like to hear from AJ is this is OK first :)
--
Dimi.
Re: Make VIRTUAL_SetFaultHandler an internal function
On Thu, Apr 14, 2005 at 03:05:36PM +0200, Alexandre Julliard wrote:
Actually it should be possible to handle the fault using a vectored
handler, without requiring internal functions at all.
Completely untested (what do people use to test DIB handling?),
but it compiles. Is something like this what you had it mind?
Index: dlls/ntdll/ntdll.spec
===
RCS file: /var/cvs/wine/dlls/ntdll/ntdll.spec,v
retrieving revision 1.175
diff -u -p -r1.175 ntdll.spec
--- dlls/ntdll/ntdll.spec 30 Mar 2005 10:22:51 - 1.175
+++ dlls/ntdll/ntdll.spec 17 Apr 2005 04:18:44 -
@@ -1035,4 +1035,3 @@
@ cdecl MODULE_DllThreadAttach(ptr)
@ cdecl MODULE_GetLoadOrderW(ptr wstr wstr)
@ cdecl VERSION_Init(wstr)
-@ cdecl VIRTUAL_SetFaultHandler(ptr ptr ptr)
Index: dlls/ntdll/virtual.c
===
RCS file: /var/cvs/wine/dlls/ntdll/virtual.c,v
retrieving revision 1.46
diff -u -p -r1.46 virtual.c
--- dlls/ntdll/virtual.c22 Feb 2005 19:33:50 - 1.46
+++ dlls/ntdll/virtual.c17 Apr 2005 04:20:14 -
@@ -212,11 +212,14 @@ void VIRTUAL_Dump(void)
*
* Find the view containing a given address. The csVirtual section must be
held by caller.
*
+ * PARAMS
+ * addr [I] Address
+ *
* RETURNS
* View: Success
* NULL: Failure
*/
-static struct file_view *VIRTUAL_FindView( const void *addr ) /* [in] Address
*/
+static struct file_view *VIRTUAL_FindView( const void *addr )
{
struct list *ptr;
@@ -473,10 +476,13 @@ static void VIRTUAL_GetWin32Prot(
*
* Build page protections from Win32 flags.
*
+ * PARAMS
+ * protect [I] Win32 protection flags
+ *
* RETURNS
* Value of page protection flags
*/
-static BYTE VIRTUAL_GetProt( DWORD protect ) /* [in] Win32 protection flags */
+static BYTE VIRTUAL_GetProt( DWORD protect )
{
BYTE vprot;
@@ -1098,25 +1104,6 @@ void virtual_init(void)
/***
- * VIRTUAL_SetFaultHandler
- */
-BOOL VIRTUAL_SetFaultHandler( LPCVOID addr, HANDLERPROC proc, LPVOID arg )
-{
-FILE_VIEW *view;
-BOOL ret = FALSE;
-
-RtlEnterCriticalSection( csVirtual );
-if ((view = VIRTUAL_FindView( addr )))
-{
-view-handlerProc = proc;
-view-handlerArg = arg;
-ret = TRUE;
-}
-RtlLeaveCriticalSection( csVirtual );
-return ret;
-}
-
-/***
* VIRTUAL_HandleFault
*/
DWORD VIRTUAL_HandleFault( LPCVOID addr )
Index: dlls/x11drv/dib.c
===
RCS file: /var/cvs/wine/dlls/x11drv/dib.c,v
retrieving revision 1.35
diff -u -p -r1.35 dib.c
--- dlls/x11drv/dib.c 14 Apr 2005 12:48:31 - 1.35
+++ dlls/x11drv/dib.c 17 Apr 2005 03:54:45 -
@@ -38,11 +38,32 @@
#include winbase.h
#include wingdi.h
#include x11drv.h
+#include excpt.h
+#include wine/list.h
#include wine/debug.h
WINE_DEFAULT_DEBUG_CHANNEL(bitmap);
WINE_DECLARE_DEBUG_CHANNEL(x11drv);
+struct mem_area
+{
+struct list entry; /* Entry in global mem area list */
+const void *base;/* Base address */
+UINT size;/* Size in bytes */
+void *data;/* Data associated with this area */
+};
+
+static struct list mem_areas_list = LIST_INIT(mem_areas_list);
+
+static CRITICAL_SECTION csMemAreas;
+static CRITICAL_SECTION_DEBUG csMemAreas_debug =
+{
+0, 0, csMemAreas,
+{ csMemAreas_debug.ProcessLocksList, csMemAreas_debug.ProcessLocksList },
+ 0, 0, { 0, (DWORD)(__FILE__ : csMemAreas) }
+};
+static CRITICAL_SECTION csMemAreas = { csMemAreas_debug, -1, 0, 0, 0, 0 };
+
static int ximageDepthTable[32];
/* This structure holds the arguments for DIB_SetImageBits() */
@@ -88,6 +109,89 @@ static INT X11DRV_DIB_Coerce(X_PHYSBITMA
static INT X11DRV_DIB_Lock(X_PHYSBITMAP *,INT,BOOL);
static void X11DRV_DIB_Unlock(X_PHYSBITMAP *,BOOL);
+/***
+ * mem_area_find
+ *
+ * Find the memory area containing a given address.
+ * The csMemAreas section must be held by caller.
+ *
+ * PARAMS
+ * addr [I] Address
+ *
+ * RETURNS
+ * Success: area
+ * Failure: NULL
+ */
+static struct mem_area *mem_area_find( const void *addr )
+{
+struct list *ptr;
+
+LIST_FOR_EACH( ptr, mem_areas_list )
+{
+struct mem_area *area = LIST_ENTRY( ptr, struct mem_area, entry );
+if (area-base addr) break;
+if ((const char*)addr (const char*)area-base + area-size) return
area;
+}
+return NULL;
+}
+
+/***
+ * mem_area_add
+ *
+ * Adds a memory area to the list.
+ *
+ * PARAMS
+ * base [I] Beginning address of the area
+ * size
Re: Move notifies around to match native
On Tue, Apr 12, 2005 at 12:24:11PM -0600, Vitaliy Margolen wrote: Also small fix for custom draw color. Native does not use colors returned from NM_CUSTOMDRAW notify. This is odd, and it deserves at the very least a comment in the code, but more preferably a unit test. -- Dimi.
Re: Move notifies around to match native
On Tue, Apr 12, 2005 at 04:13:32PM -0600, Vitaliy Margolen wrote: Well, yes and no. This is custom draw callback/notify. It shouldn't change control's parameters, such as color. At least on a permanent basis. This is what set color messages for. Agreed. But judging by what listview is doing, we do need to use them when we are drawing the item (or whatever). But I agree, we must not change those parameters permanently. Also I can't quite understand why TVM_GETITEM for iImage returns something like 0x4079D5D0 while traces show 0, 1 or 3 dependant on open/closed/has children. I guess this needs more debugging :) -- Dimi.
Re: lostwages/templates/en status_ui.template
On Sun, Apr 10, 2005 at 08:43:44PM +0200, Jacek Caban wrote: I completely disagree. We can do much more than there is done right now. shdocvw is more than WebBrowser control and we can inplement those areas, but WebBrowser needs a lot of work as well. Mozilla ActiveX Control seems not to be systematically developed and the compability we need is not their aim. We need an implementation of WebBrowser based on MSHTML, which will be possible when I finish my work on it. This way we'll be able to implement shdocvw correctly (eg. it'll be possible to implement Internet Explorer OLE Automation), but now it's far, far away from it and really far from 100% complete. This is a good discussion for WineConf. But sure, in the meantime feel free to submit a patch for this entry that better reflect your plans. In any event, I think such a significant effort probably deserves a bit bigger space somewhere else, but it will have to wait a bit until we can figure out where exactly. -- Dimi.
Re: Out-of-tree compilation and running
On Sun, Apr 10, 2005 at 11:46:38AM +0200, Detlef Riekenberg wrote: Sorry, no diff here because I changed much more in my version. Try to separate the changes, and submit a diff. I'm afraid things will go to /dev/null without one. -- Dimi.
Re: LISTVIEW_SetItemState problem in FlashFXP (and other applications)
On Sun, Apr 10, 2005 at 09:06:37PM +0200, Rolf Kalbermatter wrote:
Of course there are people here much more familiar with Common Controls
than me, so I will probably not be able to do a quick fix to this myself.
Good find! Can you test this patch?
Index: dlls/comctl32/listview.c
===
RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v
retrieving revision 1.406
diff -u -p -r1.406 listview.c
--- dlls/comctl32/listview.c25 Mar 2005 20:49:00 - 1.406
+++ dlls/comctl32/listview.c11 Apr 2005 02:37:26 -
@@ -2967,22 +2965,35 @@ static void LISTVIEW_AddGroupSelection(L
{
INT nFirst = min(infoPtr-nSelectionMark, nItem);
INT nLast = max(infoPtr-nSelectionMark, nItem);
-INT i;
+NMLVODSTATECHANGE nmlv;
LVITEMW item;
+BOOL bOldChange;
+INT i;
+
+/* Temporarily disable change notification
+ * If the control is LVS_OWNERDATA, we need to send
+ * only one LVN_ODSTATECHANGED notification.
+ * See MSDN documentation for LVN_ITEMCHANGED.
+ */
+bOldChange = infoPtr-bDoChangeNotify;
+if (infoPtr-dwStyle LVS_OWNERDATA) infoPtr-bDoChangeNotify = FALSE;
if (nFirst == -1) nFirst = nItem;
item.state = LVIS_SELECTED;
item.stateMask = LVIS_SELECTED;
-/* FIXME: this is not correct LVS_OWNERDATA
- * setting the item states individually will generate
- * a LVN_ITEMCHANGED notification for each one. Instead,
- * we have to send a LVN_ODSTATECHANGED notification.
- * See MSDN documentation for LVN_ITEMCHANGED.
- */
for (i = nFirst; i = nLast; i++)
LISTVIEW_SetItemState(infoPtr,i,item);
+
+ZeroMemory(nmlv, sizeof(nmlv));
+nmlv.iFrom = nFirst;
+nmlv.iTo = nLast;
+nmlv.uNewState = 0;
+nmlv.uOldState = item.state;
+
+notify_hdr(infoPtr, LVN_ODSTATECHANGED, (LPNMHDR)nmlv);
+infoPtr-bDoChangeNotify = bOldChange;
}
--
Dimi.
Re: Wine and Process Explorer
On Wed, Apr 06, 2005 at 07:48:11PM +0200, Paul Vriens wrote: Hi, I was just wondering if it's worthwhile to get Process Explorer running on Wine. It contains a lot of 'under-the-hood' stuff which is maybe not needed anywhere else (except the taskmgr, maybe). If you'd like to work on this task, sure -- you will probably discover and fix bugs in Wine. That's good. If you just don't know what to work on, I can suggest other things. But at the end of the day you should pick something that excites you, otherwise you're less likely to produce anything. -- Dimi.
Re: comctl32: tab unicodification
On Tue, Apr 05, 2005 at 09:04:18PM +0900, Dmitry Timoshkov wrote: Dimitrie O. Paun [EMAIL PROTECTED] wrote: infoPtr = (TAB_INFO *)Alloc (sizeof(TAB_INFO)); - SetWindowLongA(hwnd, 0, (DWORD)infoPtr); + SetWindowLongPtrW(hwnd, 0, (DWORD_PTR)infoPtr); If you change it here ... @@ -2975,7 +2952,7 @@ KillTimer(infoPtr-hwnd, TAB_HOTTRACK_TIMER); Free (infoPtr); - SetWindowLongA(infoPtr-hwnd, 0, 0); + SetWindowLongW(infoPtr-hwnd, 0, 0); ... it would be better to change it here to SetWindowLongPtrW as well. I think that moving Free (infoPtr); below of SetWindowLong would be appropriate as well. Yeah, you're right. I'll send an updated patch soon. Dimi please add -p to your default diff flags, it makes the diffs much more readable. Done. -- Dimi.
Re: Notes on adding a test
On Tue, Apr 05, 2005 at 09:17:17AM -0700, Dan Kegel wrote: Thomas Kho mentioned that http://www.geekymedia.com/twiki/bin/view.cgi/WineDev/AddingMakefile was helpful to him. Since the webmaster there says he's taking down that wiki soon, here's a copy for posterity. It would be best if someone integrated it into the Devel Guide. -- Dimi.
Re: [SERVER] fix potential leak on window.c (bug2849)
On Mon, Apr 04, 2005 at 09:38:40AM +0200, Raphael wrote:
Hi,
changelog:
- fix potential leak on window.c as seen in bug2849
+ {
+ free_region( tmp );
+ goto error;
+ }
Can you please use 4-spaces indentation, like the rest
of the file?
--
Dimi.
Re: WineConf Agenda
On Mon, Apr 04, 2005 at 04:19:36PM +1000, Andrew Tridgell wrote: Personally I think that keeping a full alternative dcache in userspace isn't the right approach. I think we could bear the hit of something that keeps O(number_of_directories) memory, but not O(number_of_files). The lack of a sensible way to auto-shrink the user space dcache in low memory situations is just one of the many problems of a full userspace dcache. But using your status bits, one can compress such a cache significantly. That is, using the fact that most files on an Unix FS are not mixed case, we can avoid storing O(number_of_files). We would then need to store all files only in r/w[1] directories with mixed case filesystems[2]. So we would be trading a little bit of memory for speed. Not a bad tradeoff these days. -- Dimi. 1. We can avoid doing so for directories that are writable by root only, those are not likely to change. 2. Essentially, those are under /home. Which means that a first order approximation would be a simple cache that works blindly on directories that match a simple regexp pattern. For most cases, that would simply be '/home/.*', and I think that would get us 90% there.
Re: Riched20: thanks + regression beta not shown
On Sun, Apr 03, 2005 at 12:32:28PM +0200, Krzysztof Foltman wrote: I'm currently working on complete tab support, and will post a patch next week. It already includes support for tab positions. This is very cool. From the limitted exposure I have with Richedit controls used in apps, this will make the current riched20 useful in 70-80% of the cases. For example, AFAICT tab support is the only feature missing to get perfect output in the richedit controls used in MS' control spy. -- Dimi.
Re: dsound: fix test to compile on vs
On Sun, Apr 03, 2005 at 01:25:22PM -0500, James Hawkins wrote: Changelog * LPLPVOID is unknown to Visual Studio, use LPVOID * instead. If so, how come it's defined in our headers? We should remove the definition if it's not standard. -- Dimi.
Re: WineConf Agenda
On Sun, Apr 03, 2005 at 08:57:58PM +1000, Andrew Tridgell wrote: In each case I will be trying to encourage methods which can store the full NTFS semantics, rather than limiting ourselves to only the things that fit natually in posix filesystems. I'm guessing we will have some lively discussion on whether this is a worthwhile aim :-) Speaking of which, both Samba and Wine suffer from the lack of support of cases-insensitivness in the kernel. Now, I'm not suggesting that we should push for that (I'm aware of the past discussions on LKML, and I must agree with Linus), but we should push for *something* that's acceptable and helps us solve the negative lookups a bit faster than a full directory listing every time. -- Dimi.
Re: WineConf Agenda
On Mon, Apr 04, 2005 at 11:08:42AM +1000, Andrew Tridgell wrote: I have a proposed solution for that which needs no kernel modifications. I have been meaning to write this up properly, so if you like I can do that for WineConf. I think it would be very good to have such a discution. It seems to me this is one performance hotpoint for both projects. - for mixed directories, Win32 names will appear lowercase to posix programs, but will be case preserving to Wine/Samba. Wine/Samba This is something I don't really like: to change the filename's case behind user's back. From my POV, it's not acceptable. I know I'd be pissed if that happened to me. I think we'd be much better off if we relied on some kernel feature. The current mechanism works just fine, if you want the same behaviour, but faster, you need such and such in the kernel. It's a much simpler (and cleaner) case to make then to change such fundamental behaviour. -- Dimi.
Re: WineConf Agenda
On Mon, Apr 04, 2005 at 11:51:02AM +1000, Andrew Tridgell wrote: It only changes the name from the point of view of posix. The name is completely preserved from the point of view of Wine/Samba. I can still understand this annoying some people, but I don't think it would annoy the majority of Samba users. I understand that, but I'd certainly fall into the minority of Samba users then. I share my /home/dimi directory via Samba to my laptop, there's no way I want my filenames modified by the system. In Wine (and I would have thought in Samba too) we try to integrate as much as possible the two (Win32 and POSIX) environments. A solution that looks good only from a Wine/Samba standpoint fails on this criteria. Obviously, we want it to look good from both perspectives simultaneously. yes, but you will run up against huge objections from the kernel community. The key sticking point is that filenames can no longer be treated as bags-of-bytes. Right. And I can understand why. But I was hoping we can get some form of support from the kernel along the lines of the bit that Linus suggested that would allow us to efficiently do the case insensitivity in user space. I think that the problem boils down to being able to maintain the state of directories in userspace in a coherent manner. If we don't get support from that in the kernel, it naturally degenerates to reading the directory every single time. If we do get support however, we shoudln't need to reread most of the time, which would be good enough. I forget now the outcome of that discussion, whatever happened to Linus' proposal for that bit? -- Dimi.
wineps: rewriting in terms of 32-bit functions
Hi Huw, Currenty wineps.dll is one of the worse offenders in terms of using non-standard, 16-bit entry points. Namely, wineps makes use of the following 16-bit functions: CloseJob16() DrvGetPrinterData16() DrvSetPrinterData16() OpenJob16() SelectVisRgn16() WriteSpool16() I was wondering if there's anything that holds us back from using 32-bit APIs instead of the 16-bit ones like so: CloseJob16() -- ClosePrinter() DrvGetPrinterData16() -- GetPrinterDataEx() DrvSetPrinterData16() -- SetPrinterDataEx() OpenJob16() -- OpenPrinter() SelectVisRgn16() -- ? WriteSpool16()-- WritePrinter() I haven't looked too deeply into the problem, but given that you probably know the code inside out, maybe you can help me put this into perspective... -- Dimi.
Re: discusion about a message loop in listview.c
On Tue, Mar 29, 2005 at 06:52:07PM +0200, Dietrich Teickner wrote: I have some weeks before reported, FlashFXP v3.02 loops with a message-loop in listview.c after login. It does this in Odin and in Wine. In Odin it stops in smaller time (deep 1000). Wine has a bigger stack, and so needs wine more time for this, bat I can see in the loog, the args for the function are more and more locatet at lower stack adresses. I have written this workarout for testing this problem in wine and in odin. with this FlashFXH 3.02 will display the contence of the server dir very fast at both environment. In the log I can see, that the message-loop was reported and stopped. I thing, we need a flag inside any item to report every function, that can called recursive, this item is in work (function-separart, or global ?), that can stop recursions of this type in the future or many programms. I have also found this try does also helps Agent 2.0 in the groups-defailt propertys (only odin-tested). This does also every crashs in earlyer builds with stack overflow in odin. Dietrich, You need to create a small example app that exhibits this behaviour such that it crashes on Wine/Odin, but runs in Windows. As things stand, I can not test with either app since they don't install under Wine. In any event, a small example app would be better, since the source would be available too. -- Dimi.
Re: wine/ windows/scroll.c dlls/x11drv/scroll.c dl ...
On Mon, Mar 28, 2005 at 02:14:44PM +0200, Rein Klazes wrote: Attached is a patch that solves Micha's scroll problem, also discussed under bug #1091. It also does not change the handling of an existing invalidated region. Nice, at least you nailed one :). As for the initial problem that I've reported (http://www.winehq.org/hypermail/wine-devel/2002/09/0748.html), you are correct, it's about interaction with the invalidated region. I've figured that while you have your hands wet in that code, maybe you can take a stab at it. Thanks for taking a look! -- Dimi.
Re: wine/ windows/scroll.c dlls/x11drv/scroll.c dl ...
On Fri, Mar 25, 2005 at 11:11:04AM -0600, Alexandre Julliard wrote: Modified files: windows: scroll.c dlls/x11drv: scroll.c dlls/user/tests: win.c msg.c Log message: Rein Klazes [EMAIL PROTECTED] ScrollDC and X11DRV_SCROLLDC should scroll only pixels coming from within the visible region, clipped to the clipping region if that exists. Add the destination of pixels coming from the outside of this region to the update region. With tests that depend on this. Patch: http://cvs.winehq.org/patch.py?id=16854 Unfortunately, this patch doesn't fix bug 1091: http://bugs.winehq.org/show_bug.cgi?id=1091 -- Dimi.
Re: ipaddress: uniform naming (take 2)
On Fri, Mar 25, 2005 at 12:05:20PM +, Mike Hearn wrote: Blah, consistency with past mistakes rather than fixing them is how Win32 ended up being such a steaming pile in the first place. If you want to do a mass search/replace why not un-hungarianize the whole file? Because out of 24 controls, only a few (maybe 2 or 3) don't use a consistent notation. And honestly, while I don't much care for the hungarian notation, I don't think it's that bad anymore to warrant such a huge renaming. And besides, the stuff that I'm renaming is code that I wrote, and so I'm sure I'm not upsetting anyone :). -- Dimi.
Re: LOSTWAGES: updates
On Fri, Mar 25, 2005 at 09:48:48PM +0900, Mike McCormack wrote: + h2Remove HeapAlloc casts/h2 Please make this a h3, all entries there are at that level. -- Dimi.
Re: saving winrash
On Thu, Mar 24, 2005 at 05:56:02PM -0600, Robert Shearman wrote: If the source to winrash was in the Wine tree I would already have fixed it by now. True, it's probably better if we have it in the tree, but last time we've tried to place it there, Alexandre refused. Truth is that one can view it as an independent project, but I doubt others will find it useful. It's too much hassle to handle it outside the tree, nobody bothers. Maybe we should ask Alexandre again? -- Dimi.
Re: Handle wParam in WM_PAINT properly
On Fri, Mar 25, 2005 at 06:50:59AM +0100, Filip Navara wrote: Hmm, MSDN says that the wParam of WM_PAINT is not used and I always believed it. Are you sure that you're not confusing it with WM_PRINTCLIENT? Yeah, it's an undocumented feature. Check out all other standard/common controls, they all support the wParam for WM_PAINT. These two were the only ones that didn't. -- Dimi.
[RFC] Pager: why do we implement WM_NCPAINT instead of WM_PAINT?
Hi folks, Does anyone know why the Pager common control (dlls/comctl32/pager.c) implements WM_NCPAINT instead of WM_PAINT? It is the only exception to the rule, all other controls implement WM_PAINT. -- Dimi.
Re: Eliminate casts of the return value of HeapAlloc
On Mon, Mar 21, 2005 at 02:03:59PM +0100, Francois Gouget wrote: On Mon, 21 Mar 2005, Alexandre Julliard wrote: [...] Log message: Mike McCormack [EMAIL PROTECTED] Eliminate casts of the return value of HeapAlloc. This could be turned into a pretty easy janitorial the starting point of which would be the output of this command: find . -name *.[ch] | xargs egrep \) *Heap(Re)?Alloc (344 lines) There are a couple of places where the output of HeapAlloc is being cast to a DWORD but except for those it seems pretty straightforward. Yeah, it's so straightforward, we should just do it. However, I don't think we should sed it, most places require human touch to maintain sane formatting. I'll send in a patch for windows/*.c shortly. -- Dimi.
Re: winmm patch
On Sat, Mar 19, 2005 at 07:46:01PM -0600, Royce Mitchell III wrote: Royce Mitchell III [EMAIL PROTECTED] - fix warning that is really a bug - from looking at the code, wDevID should be a UINT, not a UINT_16 ( perhaps these should be renamed? ) Please: 1. Send a diff -u (http://winehq.org/site/sending_patches) 2. Don't compress your submissions. -- Dimi.
Re: RICHED20: remove casts and unused code
+static inline char *RTFStrSave(char *s) Not a big deal, but the name is a bit uncommon. Wouldn't RTFStrDup() be a better/more recognizable name? -- Dimi.
Re: animate control regression
On Fri, Mar 18, 2005 at 04:21:05PM +0900, Mike McCormack wrote: If you get rid of the thread, programs that don't run a message loop or that block for a time after receiving certain messages won't animate smoothly. Yeah, I was half joking about removing it. comctl32 6.0 doesn't run a thread anymore, do you know of many/any programs that depend on that? What we had there worked, and it took quite a while to get rid of the races and lockups. Why can't we just revert to what we had? I will, it's just that I can't test the code so it will take maybe couple of iterations. I'll analize what changed in the locking today. -- Dimi.
Re: Wine FAQ removed from the doc tarballs
On Fri, Mar 18, 2005 at 01:21:06PM +0100, Francois Gouget wrote: --- revision 1.36 date: 2003-09-18 20:51:32 +; author: julliard; state: Exp; lines: +9 -5 Remove the FAQ from the doc tarball, and build it as a single .html file (based on patch by Dimitrie O. Paun). --- What's the reasoning behind this? Well, there's not much point to create .ps and .pdf versions of it IMO. This is mostly interesting for WineHQ. -- Dimi.
Re: Wine FAQ removed from the doc tarballs
On Fri, Mar 18, 2005 at 02:04:08PM +0100, Francois Gouget wrote: But I don't see any reason not to put it in wine-doc-html.tar.gz or wine-doc-txt.tar.gz. The idea of these tar files is so that one can get all the Wine documentation with just one download and the FAQ is part of the documentation. Yes, but I can not possibly see why would anyone want to download and read the FAQ like this. A FAQ is essentially a Web type of document, best view and browsed on the Web. By including it in those packages, we just make them bigger for 99.99% of the users that don't care about the FAQ, and those users are probably the ones that have most bandwidth restrictions anyway. But I'm not totally against it being there, if people feel strongly that we must, I'll go with the flow. -- Dimi.
Re: Suggestion for a couple of additional janitorial projects
On Wed, Mar 16, 2005 at 10:59:09PM +0800, Dmitry Timoshkov wrote: I'd like to suggest to add the following janitorial projects for Wine: 1. Fix Wine to be compilable by a 64-bit compiler 2. Fix wrong assumptions in Wine about endianess. I'd say go for it. -- Dimi.
Re: animate control regression
On Thu, Mar 17, 2005 at 10:31:24PM +0100, Krzysztof Foltman wrote:
The current CVS version has a regression in the animate control, causing
a deadlock, most probably in WM_DESTROY handler, in the app I'm testing
Wine with.
We should just get rid of the thread and the critical section altogether,
comctl32 6.0 is documented not to support it anymore. But before we do
that, let's try to fix this, so we have good code in CVS :)
Here is a patch completely untested (just got home at 1am, and my tree
doesn't currently build due to other problems). Can you try it out?
Index: dlls/comctl32/animate.c
===
RCS file: /var/cvs/wine/dlls/comctl32/animate.c,v
retrieving revision 1.63
diff -u -r1.63 animate.c
--- dlls/comctl32/animate.c 16 Mar 2005 19:47:52 - 1.63
+++ dlls/comctl32/animate.c 18 Mar 2005 06:00:39 -
@@ -353,15 +353,12 @@
TRACE(Drawing frame %d (loop %d)\n, infoPtr-currFrame, infoPtr-nLoop);
-EnterCriticalSection(infoPtr-cs);
-
mmioSeek(infoPtr-hMMio, infoPtr-lpIndex[infoPtr-currFrame], SEEK_SET);
mmioRead(infoPtr-hMMio, infoPtr-indata,
infoPtr-ash.dwSuggestedBufferSize);
if (infoPtr-hic
fnIC.fnICDecompress(infoPtr-hic, 0, infoPtr-inbih, infoPtr-indata,
infoPtr-outbih, infoPtr-outdata) != ICERR_OK) {
- LeaveCriticalSection(infoPtr-cs);
WARN(Decompression error\n);
return FALSE;
}
@@ -373,13 +370,9 @@
if (infoPtr-currFrame++ = infoPtr-nToFrame) {
infoPtr-currFrame = infoPtr-nFromFrame;
- if (infoPtr-nLoop != -1) {
- if (--infoPtr-nLoop == 0) {
- ANIMATE_DoStop(infoPtr);
- }
- }
+ if (infoPtr-nLoop != -1)
+ infoPtr-nLoop--;
}
-LeaveCriticalSection(infoPtr-cs);
return TRUE;
}
@@ -400,6 +393,16 @@
return 0;
}
+static LRESULT ANIMATE_Timer(ANIMATE_INFO *infoPtr)
+{
+ANIMATE_DrawFrame(infoPtr);
+
+if (infoPtr-nLoop == 0)
+ANIMATE_DoStop(infoPtr);
+
+return 0;
+}
+
static DWORD CALLBACK ANIMATE_AnimationThread(LPVOID ptr_)
{
ANIMATE_INFO *infoPtr = (ANIMATE_INFO *)ptr_;
@@ -414,6 +417,9 @@
event = infoPtr-hStopEvent;
LeaveCriticalSection(infoPtr-cs);
+if (infoPtr-nLoop == 0)
+ANIMATE_DoStop(infoPtr);
+
/* time is in microseconds, we should convert it to milliseconds */
if ((event == 0) || WaitForSingleObject( event, (timeout+500)/1000) ==
WAIT_OBJECT_0)
break;
@@ -863,7 +869,6 @@
return 0;
}
-
static LRESULT WINAPI ANIMATE_WindowProc(HWND hWnd, UINT uMsg, WPARAM wParam,
LPARAM lParam)
{
ANIMATE_INFO *infoPtr = (ANIMATE_INFO *)GetWindowLongPtrW(hWnd, 0);
@@ -905,7 +910,7 @@
return ANIMATE_StyleChanged(infoPtr, wParam, (LPSTYLESTRUCT)lParam);
case WM_TIMER:
-return ANIMATE_DrawFrame(infoPtr);
+return ANIMATE_Timer(infoPtr);
case WM_PAINT:
/* the animation isn't playing, or has not decompressed
--
Dimi.
Re: SetFocus and DefPushButton management
On Wed, Mar 16, 2005 at 10:22:51AM +0100, Katia Maculan wrote:
+ SendMessageA (dlgInfo-hwndFocus, BM_SETSTYLE,
BS_DEFPUSHBUTTON, TRUE);
^
Please use SendMessageW instead.
+ /*Check for a previous defpushbutton*/
+ if (dlgInfo-idResult)
+ {
+ hWndOldDefPushButton = GetDlgItem
(hwnd,dlgInfo-idResult);
+ if (hWndOldDefPushButton (hWndOldDefPushButton !=
dlgInfo-hwndFocus))
+ SendMessageA (hWndOldDefPushButton, BM_SETSTYLE,
BS_PUSHBUTTON, TRUE);
Ditto.
--
Dimi.
Re: animate: audit and some fixes
On Wed, Mar 16, 2005 at 08:04:26AM -0500, Tom Wickline wrote: Can you update the http://winehq.org/site/status_ui page or do you want me to? I'll update it soon, first the patch must go in :) -- Dimi.
Re: Wine's Documentation in French
On Tue, Mar 15, 2005 at 03:36:12PM +0100, Francois Gouget wrote: * WineLib User Guide José CARRENO Yvon BENOIST (proofreading) http://fgouget.free.fr/wine/winelib-user.html I'm not sure it's a good idea to translate this one. First off, this guide is quite out of date. Second, it is directed at developers, just like Wine Devel one, so maybe we shoudn't translate it at all. -- Dimi.
Re: combo - implement GetComboBoxInfo
On Mon, Mar 14, 2005 at 08:02:00PM -0800, Steven Edwards wrote: -FIXME(\n); -return FALSE; +LPHEADCOMBO lphc = (LPHEADCOMBO)GetWindowLongA( hwndCombo, 0 ); Please use GetWindowLongW(), the combo box is fully Unicode. +pcbi-hwndCombo = hwndCombo; +pcbi-hwndList = lphc-hWndLBox; +pcbi-hwndItem = lphc-hWndEdit; +pcbi-rcItem = lphc-textRect; +pcbi-rcButton = lphc-buttonRect; +pcbi-stateButton = (DWORD) lphc-wState; Fancy formatting... Bit yucky, no? -- Dimi.
Re: wine/ misc/registry.c documentation/samples/co ...
On Mon, Mar 14, 2005 at 11:18:40AM -0600, Alexandre Julliard wrote: Log message: Get rid of the remaining registry configuration parameters. Any plans on getting the global registry back? -- Dimi.
Re: Scrollkeeper, the documentation, XML, and the way forward
On Sat, Mar 12, 2005 at 04:57:22PM -0800, Scott Ritchie wrote: 1) Create a new directory for all XML documentation at wine/doc. This will also bring us to be more standard. You better check with Alexandre first, I doubt he'll go for it. 3) We follow the steps at the above link to add scrollkeeper into the configure scripts after we convert the first document to XML. I vote for the Wine User Guide, since I'm working on it. You should coordinate with Brian, he has patches waiting for the winecfg work, it would be a shame if this work creates a big problem for him. -- Dimi.
Re: wine/ misc/registry.c documentation/samples/config
On Sat, Mar 12, 2005 at 06:51:04PM +, Mike Hearn wrote: - We have no config file, yet this has apparently not accelerated the pace of winecfg development, we just have more confused users AFAIK, winecfg is not working with the real registry stuff, so how would not having a config file accelerate it's development? Let's turn winecfg on, then pass judgement on it. -- Dimi.
Re: [ARTWORK] icon: My Computer
On Sat, Mar 12, 2005 at 11:02:54PM +0100, egore wrote: Tell me if you like it, if you hate if, what could be done better, etc. -- The Desktop one is hard to distinguish at 16x16 -- Why the wine glass on the file icon? That can be confusing. -- The My Computer one is a bit busy Maybe we need special versions for the small sizes? -- Dimi.
Re: cabinet.dll FDI Conformance Test
On Fri, Mar 11, 2005 at 12:13:18AM -0800, Rizwan Kassim wrote: Wine cabinet.dll FDI Conformance Test Patch A few comments: -- the patches uses Windows line ends, please fix that -- the preprocessor is abused. There's no need to have #ifdef VERBOSE #endif all over the code, please pull that into the trace() function -- the STANDALONE business should also go, there's no need for it in Wine. -- Dimi.
Re: Make running tests on a visible desktop a mandatory requirement
On Wed, Mar 09, 2005 at 09:04:20AM +0800, Dmitry Timoshkov wrote: I know nothing about winrash, but if it's possible to tell it to run the tests on a visible desktop then it would be great. Not as far as we know. I still don't understand why you insist on killing winrash and automated testing along the way. Please fix winrash if it can be fixed, if not just find a way to sort/fiter/etc the tests better based on the visibility flag, don't prevent the ones that work from working. -- Dimi.
winebuild changes
Hi Alexandre,
Ivan found that on Windows .exe's can export functions, just
like DLLs. He needs this for his work on ntoskrnl.exe.
To support this, we need a bit of an interface change to
winebuild. I've put together a simple patch to see if you
are OK with such a change. If so, I'll finish it, and
modify winegcc accordingly.
So, thing will change as follows:
OLD: winebuild --dll=mystuff.spec
NEW: winebuild --dll -E mystuff.spec
OLD: winebuild --def=mystuff.spec
NEW: winebuild --def -E mystuff.spec
OLD: winebuild --exe=myprog.exe
NEW: winebuild --exe -F myprog.exe
to build an .exe with arbitrary exports, we would do:
winebuild --exe -F myprog.exe -E mystuff.spec
Index: tools/winebuild/main.c
===
RCS file: /var/cvs/wine/tools/winebuild/main.c,v
retrieving revision 1.59
diff -u -r1.59 main.c
--- tools/winebuild/main.c 7 Dec 2004 17:19:54 - 1.59
+++ tools/winebuild/main.c 7 Mar 2005 01:50:44 -
@@ -144,6 +144,7 @@
-C --source-dir=DIR Look for source files in DIR\n
-d --delay-lib=LIB Import the specified library in delayed mode\n
-D SYM Ignored for C flags compatibility\n
+-E --export=FILEExport the symbols defined in the .spec or .def
file\n
-e --entry=FUNC Set the DLL entry point function (default:
DllMain)\n
-f FLAGSCompiler flags (only -fPIC is supported)\n
-F --filename=DLLFILE Set the DLL filename (default: from input file
name)\n
@@ -165,9 +166,9 @@
--versionPrint the version and exit\n
-w --warnings Turn on warnings\n
\nMode options:\n
- --dll=FILE Build a .c file from a .spec or .def file\n
- --def=FILE.SPEC Build a .def file from a spec file\n
- --exe=NAME Build a .c file for the named executable\n
+ --dllBuild a .c file from a .spec or .def file\n
+ --defBuild a .def file from a spec file\n
+ --exeBuild a .c file for the named executable\n
--debug [FILES] Build a .c file with the debug channels
declarations\n
--relay16Build the 16-bit relay assembly routines\n
--relay32Build the 32-bit relay assembly routines\n\n
@@ -204,6 +205,7 @@
/* aliases for short options */
{ source-dir,1, 0, 'C' },
{ delay-lib, 1, 0, 'd' },
+{ export,1, 0, 'E' },
{ entry, 1, 0, 'e' },
{ filename, 1, 0, 'F' },
{ help, 0, 0, 'h' },
@@ -248,6 +250,10 @@
case 'D':
/* ignored */
break;
+case 'E':
+spec_file_name = xstrdup( optarg );
+set_dll_file_name( optarg, spec );
+break;
case 'F':
spec-file_name = xstrdup( optarg );
break;
@@ -324,21 +330,12 @@
break;
case LONG_OPT_DLL:
set_exec_mode( MODE_DLL );
-spec_file_name = xstrdup( optarg );
-set_dll_file_name( optarg, spec );
break;
case LONG_OPT_DEF:
set_exec_mode( MODE_DEF );
-spec_file_name = xstrdup( optarg );
-set_dll_file_name( optarg, spec );
break;
case LONG_OPT_EXE:
set_exec_mode( MODE_EXE );
-if ((p = strrchr( optarg, '/' ))) p++;
-else p = optarg;
-spec-file_name = xmalloc( strlen(p) + 5 );
-strcpy( spec-file_name, p );
-if (!strchr( spec-file_name, '.' )) strcat( spec-file_name,
.exe );
if (!spec-subsystem) spec-subsystem =
IMAGE_SUBSYSTEM_WINDOWS_GUI;
break;
case LONG_OPT_DEBUG:
--
Dimi.
Wine logo (the glass)
Folks, do we have an .svg version of the logo? If so, where can I get it from? -- Dimi.
Re: FlashFXP v 3.01 and wine + Odin
On Sat, Mar 05, 2005 at 08:23:11PM +0100, Dietrich Teickner wrote: the child ask the parent, this ask the child, this ask the parrennt, this. never end, only if the stack at end. How did you get this trace? Can you send a +listview trace? -- Dimi.
Re: imagelist: style fixes
On Thu, Mar 03, 2005 at 11:13:49AM +0100, Alexandre Julliard wrote: I knew I was going to regret applying Mike's indentation patches... Folks, please let's not start an indentation police, there's no reason to fix anything unless a file is really so messed up that it becomes unreadable. This has nothing to do with Mike's patches. I've been doing this work on the controls for more than 2 years now. I audit the code, fix things, etc. This is no police BTW, I was just making the files consistent. In this case, more then 90% of the file uses one style, there's really no reason to mix and match :) -- Dimi.
Re: Use of STLPort with winegcc
On Thu, Mar 03, 2005 at 10:23:51AM +0200, Boaz Harrosh wrote: What would be the right way to do it? I would submit a patch, but what should I do? Just append the -I .../msvcrt instead of prepend, or maybe use -isystem .../msvcrt. The docs for gcc say that -isystem folders will be searched before the default gcc folders but after any -I folders. The problem is that winegcc handling of msvcrt/ and windows/ dir is broken. They should be added with -isystem instead of -I. -- Dimi.
Re: Visual C++ 6.0 as a Winelib IDE?
On Wed, Mar 02, 2005 at 05:22:24AM -0800, Ira Krakow wrote: The Makefile that Winemaker generates _almost_ works. You need to delete the references to the mfc library and mfc.dll. After doing that, running make generates the .so file. Wine runs it flawlessly. Nice! I got to thinking - can I convert the code from the MFC application as easily? Seems like it's doable, because the generated code runs in VC++/Crossover Office 4.1. I tried the same steps as before, with Winemaker, but I couldn't figure out what Makefile modifications were needed. For MFC apps, I think you need to recompile MFC with Wine first. All of this got me to thinking - could Wine running Visual C++ be a viable IDE for porting? Maybe just linking VC++ with the Winelib libraries would do it. This can't be done, we don't have VC++ sources. And besides, you don't get any additional benefits as compared to just running the native PE. -- Dimi.
Re: Dump HeapWalk entries
On Wed, Mar 02, 2005 at 05:52:45PM +0100, Uwe Bonnes wrote:
+ if ((entry-wFlags PROCESS_HEAP_ENTRY_BUSY )
+ (entry-wFlags PROCESS_HEAP_ENTRY_MOVEABLE))
+{
+ /* Treat as block */
+ DPRINTF( BLOCK-hMem\t\t:%08lx\n, (DWORD)entry-u.Block.hMem);
+}
Please don't introduce _another_ style of brackets, just use the
one that's used in the file. Should be either:
if () {
}
or
if ()
{
}
--
Dimi.
Re: wine-user.pdf feedback
On Wed, Mar 02, 2005 at 01:12:06AM -0500, Dan W. wrote: crap questions to you, but to me it's a solid and tangible one. Well, I do know that I do have wine installed, because when I installed Fedora Core 2, I said install everything. Besides, I tried.. wine /mnt/C/windows/notepad.exe and it worked :-) :-) :-) Do: which wine to figure out if it's installed. But as for the version of wine I have, I have no idea how to find out. wine --version installed in ONE folder, and not many. Looks like many, by the looks of it... Or at least two: One under /usr/local, which only contains two files, another for documentation, elsewhere, and I saw a folder somewhere with alotof.dll.so files. Under multiple folders, don't worry where it is. apps to run on Linux, I might succeed at having the company switch over. Wish me luck. Fingers and toes crossed! :) -- Dimi.
Re: vartest.c - major pain in the build process
On Mon, Feb 28, 2005 at 01:10:25PM +0100, Ivan Leo Puoti wrote: OK, then we can have winrash only run them in interactive mode, end of story. Don't need to do that, there are plenty of tests that run fine with an invisible desktop, there's enough value in having some automated tests. Maybe we need to separate the results... -- Dimi.
Re: comctl32 - SB_SETBORDERS
On Mon, Feb 28, 2005 at 01:04:23AM +0100, Thomas Weidenmueller wrote: Even though Office tries to use them I oppose implementing it. Why? There's little harm in supporting it, if some versions of the real thing does. It's neither difficult, nor complex... -- Dimi.
Re: broken faq.sgml
On Thu, Feb 24, 2005 at 08:12:10PM +0300, Vitaly Lipatov wrote: jade:/home/lav/RPM/BUILD/wine-20050224/documentation/faq.sgml:1716:66:Q: length of name token must not exceed NAMELEN (44) Thanks, sorry for the problem. ChangeLog Shorten the id of the question to avoid jade error. cvs diff documentation/faq.sgml Index: documentation/faq.sgml === RCS file: /var/cvs/wine/documentation/faq.sgml,v retrieving revision 1.40 diff -u -r1.40 faq.sgml --- documentation/faq.sgml 24 Feb 2005 10:08:15 - 1.40 +++ documentation/faq.sgml 24 Feb 2005 18:51:21 - @@ -1713,7 +1713,7 @@ /qandaentry qandaentry - question id=Can-I-bundle-everything-in-one-huge-executable + question id=Can-I-bundle-everything-in-one-huge-exe para Is there a way to bind the Wine code, a Windows .exe, associated DLLs, and any necessary accompanying files into a single Linux executable which -- Dimi.
Re: Compiling wine dlls for windows
On Thu, Feb 24, 2005 at 09:19:15PM +0100, Hans Leidekker wrote: Among other possibilities, if you have an RPM based distro you could use my MinGW cross compiler RPM packages, prebuilt for Fedora Core and SUSE but also available as source RPMS to rebuild yourself: It may be a good idea to have these instructions included in our Wine Devel docs. They seem to surface from time to time, we could just point people to them. -- Dimi.
Re: Collection of wine tools on windows
On Sun, Feb 20, 2005 at 07:48:40PM +0200, Boaz Harrosh wrote: 1) MinGW header-set are Evil - Because they are ugly, with this, no variables names, and all this style for machines guide. This I already carry for 10 years so here it is off my chest. Heh, the MinGW folks seem to have some strange requirements for their headers, I don't think they'll drop theirs. But we can start by having ReactOS adopt our headers. We should also offer our headers as a separate package that works out of the box as a replacement for the MinGW ones. This way people can just get our headers if they are better than the MinGW ones. -- Dimi.
Re: Text Alignment, how is it handled ?
On Mon, Feb 07, 2005 at 04:07:06PM +0100, George Ginden wrote: Hi the following code part is not working in Wine as it work (as supposed) in Windows. HRight = GetDlgItem (hDlg,IDC_RIGHT); Edit_SetText(HRight, Right); How is text alignment, in a edit field, handled ? Currently, our edit box (dlls/user/edit.c) does not support right-aligned fields. It is a known limitation. If you want you can try to implement it, and submit a patch. -- Dimi.
Re: my first go at syncing opengl spec
On Fri, Feb 04, 2005 at 01:58:35PM -0500, Tom wrote: This is my first attempt at syncing the opengl spec. Is this close to what needs to be done? I don't know, I can't view it. Please no compressed patches. And for sure not bzip2, if you *have* to do it, use gzip. This way I can view it via zless. -- Dimi.
Re: x11drv regression?
On Tue, Feb 01, 2005 at 07:27:32AM -0600, Jeremy White wrote: If Alexandre committed a patch that converted the entire code base from C to pure assembler, his changelog would read: Code optimizations :) Truth be told however, Alexandre is annoyingly to the point. :) So no, I don't think he's overly terse. -- Dimi.
Re: wine/dlls x11drv/x11drv.h x11drv/winpos.c x11d ...
On Mon, Jan 31, 2005 at 08:26:24PM +0100, Alexandre Julliard wrote: The bulk of the architectural work is done, yes. This is a big day then -- pretty cool stuff. There are still many loose ends to tie up, and some missing performance improvements. Plus of course fixing all the regressions that this change will cause, notably with OpenGL... If it's not too much trouble, it would be nice if you list all the known loose ends/bugs/optimisations/regressions so that (1) we can explicitly track them, and (2) we get a sense of where we are and how things are going. And last, but not least, there is the off chance that someone might lend a helping hand (yeah, I know, chances are slim to none, but still ... :)) -- Dimi.
Re: Refcounting in dsound
On Mon, Jan 24, 2005 at 02:50:02PM +0100, Paul Vriens wrote: Is there a need to clean (i.e. use Interlocked*) this up? I thought we've decided to have all mods go through Interlocked*, for consistency... -- Dimi.
Re: Wine Knowledge Base
On Sun, Jan 23, 2005 at 01:03:23PM +, Mike Hearn wrote: http://navi.cx/svn/misc/trunk/winekb/index.xml This is nice, but I'm not sure I agree with your rationale for not using a real Wiki. - Easy to improve It is easy, but not as easy a regular Wiki. By a long shot. Moreover a Wiki like MoinMoin is so common on the web that people know it, and they don't have to lear yet another markup format. And you can not compare the click-to-edit--edit--click-to-save ease of using a Wiki with the procedure to change this one (mentioning svk, diff, mail, etc, and you've lost 95% of people, right there). - Visually appealing This is in the eye of the beholder. I am sorry, but MoinMoin doesn't look at all that bad that it's a reason to reinvent the wheel. Besides, a real Wiki has nice features (email notifications, history, etc) that we are all missing with a hand-rolled one. - Controlled This has been a non-argument from the beginning. Jer has been put off by the silly FAQ-O-Matic, but that wasn't really a Wiki. There are so many Wikis on the web that work just fine and are useful (see the Arch Wiki, and so many others) that this has no support whatsoever. In fact, the lack of control (and the associated ease of editting) are the very reason to use Wikis, and we are giving these up for some irrational fears. Let's add a Wiki to the main site (MoinMoin in particular), and see what happens. If it doesn't work out, we'll take it down. I'm sure people will love it. -- Dimi.
Re: MSI: indentation and style cleanup
On Sat, Jan 22, 2005 at 05:16:45PM +, Mike Hearn wrote: Given that it can be quite complex and introduce new bugs, and given that it's really quite a useless feature IMHO as modern Linux boxes will hang themselves in swap hell before returning NULL from malloc I don't think this should be a janitorial project. I suspect that some of the cases will be simple, some a bit more complicated, a few quite involved. However, it's not that difficult to 'get' what you need to do, so if someone picks up the task, they'll get it within a few patches. ANd they can start with the simple stuff, BTW. At the very list, I think it's worth having the script. And while we're at it, we might as well have the list, for curiosity's sake. :) -- Dimi.
Re: Wine Knowledge Base
On Sun, Jan 23, 2005 at 07:44:27PM +, Mike Hearn wrote: If you can convince Newman then I'll owe you beer at WineConf (you're coming, right?). Yes, I'm coming. And I hope to get that beer :) -- Dimi.
Re: [Fwd: Wine-Wiki.org]
On Mon, Jan 24, 2005 at 02:24:48AM +0100, Ivan Leo Puoti wrote: If the appdb isn't good enough, we should fix it, not link to third party web sites. The AppDB will never replace a Wiki. They serve different purposes. Trying to shoehorn everything in AppDB is a (big) mistake IMO. We need an official Wiki. I suggest MoinMoin. -- Dimi.
Re: Compiling the MFC using Winelib
On Sat, Jan 22, 2005 at 01:19:35PM -0800, Dan Dennison wrote: So as a service to the Wine community I plan to document the process of building libmfc as part of my master's project. Although the MFC is not the focus of this project, porting of it is a requirement for the package to work using Winelib. Cool, this would be very valuable indeed. Are there resources available beyond simple compilation tips to assist in the building of the MFC library under Winelib? All we have is this: http://winehq.org/site/winelib#atlmfc -- Dimi.
Re: fix the DEVELOPER-HINTS file to reflect how things are really done
On Fri, Jan 21, 2005 at 04:54:29PM +0900, Mike McCormack wrote: - FIXME((%x,%p,%d): stub\n, hdc, p, count); ... + FIXME(%p %p %ld\n, hdc, p, count); Well, I must agree with Andy: there's no reason to remove the 'stub' part, most of the code uses it, automated tools look for it, and it saves nothing. -- Dimi.
Re: janitorial: COM status update
On Fri, Jan 21, 2005 at 07:39:55PM -0500, Tom wrote: I beleive this is the way it should be done (class=submitted) instead of removing completed entries. It's close enough to completion that I think we can just remove them now. The page is getting pretty big anyway, so removing them actually helps. -- Dimi.
Re: [LOSTWAGES] update the non-standard include files task
Actually, you missed a few things. ChangeLog A few non-standard include files are gone. -- Dimi. ? diffs Index: templates/en/janitorial.template === RCS file: /home/wine/lostwages/templates/en/janitorial.template,v retrieving revision 1.64 diff -u -r1.64 janitorial.template --- templates/en/janitorial.template19 Jan 2005 16:54:31 - 1.64 +++ templates/en/janitorial.template20 Jan 2005 05:50:48 - @@ -195,7 +195,7 @@ The ASCII to Unicode conversion is lossy; moreover, with the shift to Unicode, it's actually slower to deal in ASCII than in Unicode, because of the additional conversions required. - There are 43 cross calls from Unicode to ANSI as reported by + There are 40 cross calls from Unicode to ANSI as reported by tttools/winapi_check/winapi_check --none --progress --cross-call-unicode-ascii/tt (as of Jan 11, 2005): ul @@ -326,7 +326,6 @@ related to the bDLL Separation/b task, listed above. There are 16 Wine-only headers that need to be moved, as of Aug 12, 2004: ul -li async.h li builtin16.h li cursoricon.h li dce.h @@ -336,16 +335,15 @@ li local.h li miscemu.h li module.h -li nonclient.h li stackframe.h li thread.h -li win.h li winpos.h /ul ul -liworkers: a href=mailto:[EMAIL PROTECTED]Alexandre Julliard/a. +liworkers: a href=mailto:[EMAIL PROTECTED]Alexandre Julliard/a, +a href=mailto:[EMAIL PROTECTED]Eric Pouech/a. listatus: span class=inprogressfirst patches committed./span -liupdated: Dec 6, 2002 +liupdated: Jan 20, 2005 /ul h3Remove non-standard directories/h3
Re: WineHQ:winetest: produce valid HTML
On Mon, Jan 17, 2005 at 11:30:53AM +0100, Ferenc Wagner wrote: I would prefer to have all failed tests at the top, so one could see easily which ones need to be fixed. Not being an addition but a change, I'd like to hear others' opinion on this matter. I agree, it's not worth losing alphabetical ordering. It would also be nice if the author of a test got an email whenever a test failed. Finding out the author of a test isn't easy, it requires some digging into CVS. And we can't just do it, we need opt-ins, etc. Not worth it IMO. -- Dimi.
Re: The use of a zero flag
On Thu, Jan 13, 2005 at 04:14:36PM +0100, Francois Gouget wrote: The previous script doesn't. Handling this is a bit more tricky, mostly because of sed's restrictions on regular expressions. Heh, nice script. Maybe we should have such an item on the page after all, maybe together with the script? -- Dimi.
WineHQ: suggested improvement
Hi folks, I haven't looked at the template system to see how easy this would be, but I have one problem with the site as it is now, that may be very easy to solve. Namely, when you load it first time, the browser doesn't know to render all the corners (since they are all images), and as a result the layout happens in stages, and it's annoying. Can we please provide _explicit_ sizes for imges like these: img src=./images/winehq_border_top_right.gif alt= img src=./images/winehq_border_bottom_right.gif alt= ... This should take care of this little annoyance, and would make the site feel better. -- Dimi.
Re: WineHQ:winetest: produce valid HTML
On Wed, Jan 12, 2005 at 05:29:18PM +0100, Ferenc Wagner wrote: ChangeLog: * Generate valid HTML 4.01 Strict. * Underline vis_note class links, too. Cool stuff Feri. Anyone knows what happened to the tests? The last one at http://test.winehq.org/data/ is 2004-12-28. Also, the last tests build at SF is winetest-200409111000 which is a bit outdated :) What gives? -- Dimi.
Re: The use of a zero flag
On Wed, Jan 12, 2005 at 09:04:20PM +0100, Paul Vriens wrote: Is it worthwhile to set up a Janitorial task for this or are these plain bugs? On the one hand it will be hard to find these and you have to know the code of course. Yeah, I think it's worthwhile to look at such cases, but I don't think we should have a janitorial task for them: they are far and few in between, hard to find, etc. -- Dimi.
Re: WineHQ:winetest: produce valid HTML
On Wed, Jan 12, 2005 at 05:29:36PM +, Mike Hearn wrote: Is there a todo list of what needs to be done for winetest anywhere? This is what I had in mind: * We need a page under http://www.winehq.org/site/status (in the right-hand box) which should contain: -- an explanation for the entire winetest business -- ditto for winrash (http://winrash.sf.net) -- pointers to where they can download them (tests winrash) -- how they can help by actually running them (winrash is preferred) -- instructions on how to install winrash -- a legend for the test pages -- links to the last 10 most recent results * Also, http://test.winehq.org/ should contain: -- a short description of the results -- a link to the http://www.winehq.org/site/status, for full details -- the above mentioned legend for the results -- a summary with links to all test results (for bonus points, display them in calendar form). -- Dimi.
Re: WineHQ:winetest: produce valid HTML
On Wed, Jan 12, 2005 at 06:58:19PM -0500, Kevin Koltzau wrote: I actually gave up keeping the sourceforge upload working, I am however still building winetest. Sourceforge made some changes to their site that broke sfutils. I had thought about hosting the builds on wine.sourceforge.net, which I mentioned on the list some time ago with no response. Hmm, that would be cool. For reasons I can not understand, I can not access Paul's site at www.astro.gla.ac.uk, so having them available somewhere else would be very good for me. -- Dimi.
Re: WineHQ:winetest: produce valid HTML
On Thu, Jan 13, 2005 at 01:11:35AM +, Paul Millar wrote: Could you do a bit more investigation, like host www.astro.gla.ac.uk? Here you go: [EMAIL PROTECTED] ~]$ host www.astro.gla.ac.uk www.astro.gla.ac.uk is an alias for terra.astro.gla.ac.uk. terra.astro.gla.ac.uk has address 130.209.45.194 [EMAIL PROTECTED] ~]$ traceroute www.astro.gla.ac.uk traceroute to terra.astro.gla.ac.uk (130.209.45.194), 30 hops max, 38 byte packets 1 lattica.com (192.168.3.1) 0.519 ms 0.404 ms 0.331 ms 2 * * * 3 gw03-vlan201.wlfdle.phub.net.cable.rogers.com (66.185.90.161) 18.194 ms 6.477 ms 35.257 ms 4 gw01-vlan962.wlfdle.phub.net.cable.rogers.com (66.185.93.69) 8.538 ms 8.966 ms 25.388 ms 5 gw02.wlfdle.phub.net.cable.rogers.com (66.185.80.130) 14.756 ms 8.939 ms 52.187 ms 6 * * * 7 p13-0.core02.ord01.atlas.cogentco.com (66.28.4.213) 25.295 ms 22.545 ms 23.932 ms 8 p15-0.core01.ord03.atlas.cogentco.com (154.54.2.242) 22.971 ms 24.112 ms 24.849 ms 9 4.68.127.129 (4.68.127.129) 69.403 ms 36.608 ms 66.020 ms 10 so-2-1-0.bbr2.Chicago1.Level3.net (209.244.8.13) 57.766 ms 78.712 ms 37.232 ms 11 so-2-0-0.bbr2.Washington1.Level3.net (209.247.10.130) 35.877 ms 69.783 ms 39.840 ms 12 as-0-0.bbr1.London2.Level3.net (4.68.128.101) 111.231 ms 164.851 ms 180.228 ms 13 ge-3-0-0.gar1.London2.Level3.net (4.68.124.62) 102.045 ms 105.203 ms 103.338 ms 14 195.50.116.202 (195.50.116.202) 136.914 ms 144.620 ms 125.928 ms 15 po2-0.lond-scr4.ja.net (146.97.35.221) 114.603 ms 136.163 ms 101.644 ms 16 po1-0.read-scr.ja.net (146.97.33.26) 101.265 ms 112.260 ms 124.663 ms 17 po3-0.warr-scr.ja.net (146.97.33.54) 105.411 ms 106.434 ms 113.055 ms 18 po2-0.glas-scr.ja.net (146.97.33.58) 158.310 ms 119.836 ms 151.558 ms 19 po0-0.glasgow-bar.ja.net (146.97.35.54) 110.029 ms 110.312 ms 110.151 ms 20 146.97.40.106 (146.97.40.106) 152.059 ms 123.885 ms 111.152 ms 21 130.209.2.117 (130.209.2.117) 129.663 ms 160.970 ms 133.687 ms 22 130.209.2.2 (130.209.2.2) 112.559 ms 110.315 ms 123.665 ms 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * -- Dimi.
Re: WineHQ:winetest: produce valid HTML
On Thu, Jan 13, 2005 at 02:24:21AM +0100, Ferenc Wagner wrote: Can't you even ping the server? If not, what does traceroute say? If yes, your IP number must be blacklisted at Glasgow... ;) No, I can't ping either: [EMAIL PROTECTED] ~]$ ping www.astro.gla.ac.uk PING terra.astro.gla.ac.uk (130.209.45.194) 56(84) bytes of data. --- terra.astro.gla.ac.uk ping statistics --- 24 packets transmitted, 0 received, 100% packet loss, time 22998ms -- Dimi.
