NOTIFY_PRE and NOTIFY_POST definitions in include files
Hi, just found the following: [EMAIL PROTECTED] include]$ grep -e NOTIFY_PRE -e NOTIFY_POST * netspi.h:#define NOTIFY_PRE 0x00 netspi.h:#define NOTIFY_POST 0x01 npapi.h:#define NOTIFY_PRE 0x0001 npapi.h:#define NOTIFY_POST 0x0002 this doesn't look right although they do not seem to be used anywhere in the code currently. Any comments? Cheers, Paul.
Re: The use of a zero flag
Paul Vriens wrote: >a few days ago I found a bug in ole32/compobj.c where we did something >like: > >if ( foo & FLAG) where FLAG=0 > >This 'inspired' me to check for more of these kind of checks. > >One that I already found is in dlls/dplayx/dplay.c > >We are checking for DPSET_REMOTE (which is zero) where we should have >checked for !DPSET_LOCAL or something alike. Often flag sets with a zero flag are more like an enumeration than real flags and have some sort of mask defined which specifies which bits are relevant for that group of flags. Microsoft does something mix real flags and enumeration flags in the same integer but always at different bit locations. Something like if ((foo & MASK) == FLAG) will usually work fine then. Rolf Kalbermatter
Re: WineHQ:winetest: produce valid HTML
Dimi, Both these results are what I get from remote hosts that can access the web pages, so unfortunately don't shed any light on the issue. As a shot in the dark, have you got either ECN set, or a non-zero default window-scaling? Which kernel are you running? cat /proc/sys/net/ipv4/tcp_ecn cat /proc/sys/net/ipv4/tcp_default_win_scale Cheers, Paul. On Thursday 13 January 2005 01:57, Dimitrie O. Paun wrote: > 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 * * * pgp4SOPuPcj11.pgp Description: PGP signature
Re: NOTIFY_PRE and NOTIFY_POST definitions in include files
On Thu, 13 Jan 2005, Paul Vriens wrote: Hi, just found the following: [EMAIL PROTECTED] include]$ grep -e NOTIFY_PRE -e NOTIFY_POST * netspi.h:#define NOTIFY_PRE 0x00 netspi.h:#define NOTIFY_POST 0x01 I don't find netspi.h in the Platform SDK. I also don't find any of the definitions it contains. npapi.h:#define NOTIFY_PRE 0x0001 npapi.h:#define NOTIFY_POST 0x0002 However I can confirm these values. So I would say the correct values are the ones in npapi.h and that netspi.h should be moved to dlls/mpr which is the only place where it is used. But this needs a bit more investigation. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95
Re: The use of a zero flag
On Wed, 12 Jan 2005, Dimitrie O. Paun wrote: 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. Actually it's not that hard. You can even do it with a one-line bash script: regexp=`sed -e 's/^ *# *define *\([a-zA-Z_][a-zA-Z0-9_]*\) *0 *$/\1/' -e 't' -e 's/^ *# *define *\([a-zA-Z_][a-zA-Z0-9_]*\) *0x00*L* *$/\1/' -e 't' -e 'd' include/*.h`;regexp=`echo $regexp | sed -e 's/ NULL / /' -e 's/ /|/g'`;egrep -r -n "& *($regexp)[^a-zA-Z0-9_]" . Ok, it's a long line but it's just one line anyway. Here's what I get: ./dlls/comctl32/listview.c:6297:if (nColumn == 0 || lpColumn->fmt & LVCFMT_LEFT) ./dlls/comctl32/pager.c:844:if (!(dwStyle & PGS_HORZ) && !(dwStyle & PGS_VERT)) ./dlls/commdlg/filedlgbrowser.c:320:(wFlags & SBSP_ABSOLUTE) ? "SBSP_ABSOLUTE" : "SBPS_"); ./dlls/dplayx/dplay.c:1164: if( ( dwFlags & DPSET_REMOTE ) && ./dlls/dplayx/dplay.c:1180:if( dwFlags & DPSET_REMOTE ) ./dlls/dplayx/dplay.c:1363: if( ( dwFlags & DPSET_REMOTE ) && ./dlls/dplayx/dplay.c:1379:if( dwFlags & DPSET_REMOTE ) ./dlls/dplayx/dplay.c:2430: if( dwFlags & DPSET_REMOTE ) ./dlls/dplayx/dplay.c:2635: if( dwFlags & DPSET_REMOTE ) ./dlls/dplayx/dplay.c:3061: if( dwFlags & DPSET_REMOTE ) ./dlls/dplayx/dplay.c:3074: if( dwFlags & DPSET_REMOTE ) ./dlls/dplayx/dplay.c:3159: if( dwFlags & DPSET_REMOTE ) ./dlls/dplayx/dplay.c:3169: if( dwFlags & DPSET_REMOTE ) ./dlls/winmm/mciseq/mcimidi.c:1359: if (lpParms->dwAudio & MCI_SET_AUDIO_ALL) ./dlls/winmm/mciwave/mciwave.c:1233:if (lpParms->dwAudio & MCI_SET_AUDIO_ALL) False positives: ./dlls/psapi/tests/module.c:95:ok((retval && ERROR_SUCCESS == GetLastError()) || ./dlls/psapi/tests/module.c:119:ok( (retval && ERROR_SUCCESS == GetLastError()) || -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.
Re: The use of a zero flag
> > regexp=`sed -e 's/^ *# *define *\([a-zA-Z_][a-zA-Z0-9_]*\) *0 *$/\1/' -e > 't' -e 's/^ *# *define *\([a-zA-Z_][a-zA-Z0-9_]*\) *0x00*L* *$/\1/' -e 't' > -e 'd' include/*.h`;regexp=`echo $regexp | sed -e 's/ NULL / /' -e 's/ > /|/g'`;egrep -r -n "& *($regexp)[^a-zA-Z0-9_]" . > > Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ > Linux: It is now safe to turn on your computer. > > Hi Francois, how do you cater for the following in your one-liner: include/accctrl.h:#define ACTRL_RESERVED 0x include/accctrl.h:#define ACTRL_DS_OPEN ACTRL_RESERVED good luck :-) But seriously what would be the best way to fix up dplayx.c? Cheers, Paul.
Re: WineHQ:winetest: produce valid HTML
On Wednesday 12 January 2005 22:12, Ferenc Wagner wrote: > SF downloads page. Paul Millar, however, kept up with the > load until the new GUIDs broke MinGW again. We already > talked about the issue and Hans Leidekker also confirmed the > MinGW problem, but hasn't got around to provide a patch yet. > If Paul can use Stefan's patch, then new builds can be > expected real soon, I guess. I've put a couple of new RPMs on my page: http://mirzam.it.vu.nl/mingw/ >From the changelog: - update mingw-runtime to 3.6 - update w32api to 3.2 - add mscms import library. - add msi import library. - add a uuid needed by MAPI tests - rebuild on Fedora Core 3 These allow me to cross build all tests in current cvs. -Hans
Code cleanup: SHFileOperationW
Hi,
I took out a part of the function SHFileOperationW and put it in a new
function - please give any comments: is this the way to make this
function more readable you want it? what is a better way of calling such
a function?
regards,
Joris
? .patch.diff.swp
? backup-010320051808-pre-wine.tgz
? backup-010920052053-pre-wine.tgz
? backup-011120051329-pre-wine.tgz
? backup-011120051339-pre-wine.tgz
? backup-011220050008-pre-wine.tgz
? backup-123120041614-pre-wine.tgz
? badrefs
? description-pak
? doc-pak
? getrefs
? patch.diff
? ref
? refs
? versions
? wine-working.deb
? wine_cvs-041231-1_i386.deb
? wine_cvs-050103-1_i386.deb
? wine_cvs-050109-1_i386.deb
? wine_cvs-050111.noalsa-1_i386.deb
? wine_cvs-050112.release-1_i386.deb
? programs/notepad2
Index: dlls/shell32/shlfileop.c
===
RCS file: /home/wine/wine/dlls/shell32/shlfileop.c,v
retrieving revision 1.50
diff -u -r1.50 shlfileop.c
--- dlls/shell32/shlfileop.c23 Dec 2004 17:12:07 - 1.50
+++ dlls/shell32/shlfileop.c13 Jan 2005 14:13:33 -
@@ -861,6 +861,40 @@
#define ERROR_SHELL_INTERNAL_FILE_NOT_FOUND 1026
#define HIGH_ADR (LPWSTR)0x
+static int WINAPI SHFileOperationW_delete( WIN32_FIND_DATAW
*wfd,SHFILEOPSTRUCTW nFileOp, LPWSTR pFromFile,LPWSTR pTempFrom,HANDLE hFind)
+
+{
+LPWSTR lpFileName;
+BOOLb_Mask = (NULL != StrPBrkW(&pFromFile[1], wWildcardChars));
+int retCode = 0;
+do
+{
+lpFileName = wfd->cAlternateFileName;
+if (!lpFileName[0])
+lpFileName = wfd->cFileName;
+if (IsDotDir(lpFileName) ||
+((b_Mask) && IsAttribDir(wfd->dwFileAttributes) &&
(nFileOp.fFlags & FOF_FILESONLY)))
+continue;
+SHFileStrCpyCatW(&pFromFile[1], lpFileName, NULL);
+/* TODO: Check the SHELL_DeleteFileOrDirectoryW() function in
shell32.dll */
+if (IsAttribFile(wfd->dwFileAttributes))
+{
+if(SHNotifyDeleteFileW(pTempFrom) != ERROR_SUCCESS)
+{
+nFileOp.fAnyOperationsAborted = TRUE;
+retCode = 0x78; /* value unknown */
+}
+}
+else if(!SHELL_DeleteDirectoryW(pTempFrom, (!(nFileOp.fFlags &
FOF_NOCONFIRMATION
+{
+nFileOp.fAnyOperationsAborted = TRUE;
+retCode = 0x79; /* value unknown */
+}
+}
+while (!nFileOp.fAnyOperationsAborted && FindNextFileW(hFind,wfd));
+return retCode;
+}
+
/*
* SHFileOperationW [EMAIL PROTECTED]
*
@@ -1080,33 +1114,9 @@
/* ??? b_Mask = (!SHFileStrICmpA(&pFromFile[1], &wfd.cFileName[0],
HIGH_ADR, HIGH_ADR)); */
if (!pTo) /* FO_DELETE */
{
-do
-{
-lpFileName = wfd.cAlternateFileName;
-if (!lpFileName[0])
-lpFileName = wfd.cFileName;
-if (IsDotDir(lpFileName) ||
-((b_Mask) && IsAttribDir(wfd.dwFileAttributes) &&
(nFileOp.fFlags & FOF_FILESONLY)))
-continue;
-SHFileStrCpyCatW(&pFromFile[1], lpFileName, NULL);
-/* TODO: Check the SHELL_DeleteFileOrDirectoryW() function
in shell32.dll */
-if (IsAttribFile(wfd.dwFileAttributes))
-{
-if(SHNotifyDeleteFileW(pTempFrom) != ERROR_SUCCESS)
-{
-nFileOp.fAnyOperationsAborted = TRUE;
-retCode = 0x78; /* value unknown */
-}
-}
-else
-{
-if(!SHELL_DeleteDirectoryW(pTempFrom,
(!(nFileOp.fFlags & FOF_NOCONFIRMATION
-{
-nFileOp.fAnyOperationsAborted = TRUE;
-retCode = 0x79; /* value unknown */
-}
-}
-} while (!nFileOp.fAnyOperationsAborted &&
FindNextFileW(hFind, &wfd));
+ int ret =
SHFileOperationW_delete(&wfd,nFileOp,pFromFile,pTempFrom,hFind);
+ if (ret != 0)
+retCode = ret;
FindClose(hFind);
hFind = INVALID_HANDLE_VALUE;
if (nFileOp.fAnyOperationsAborted)
Index: dlls/wined3d/basetexture.c
===
RCS file: /home/wine/wine/dlls/wined3d/basetexture.c,v
retrieving revision 1.2
diff -u -r1.2 basetexture.c
--- dlls/wined3d/basetexture.c 9 Jan 2005 17:37:02 - 1.2
+++ dlls/wined3d/basetexture.c 13 Jan 2005 14:13:34 -
@@ -37,16 +37,17 @@
ULONG WINAPI IWineD3DBaseTextureImpl_AddRef(IWineD3DBaseTexture *iface) {
IWineD3DBaseTextureImpl *This = (IWineD3DBaseTextureImpl *)iface;
-TRACE(
Re: WineHQ:winetest: produce valid HTML
On Thursday 13 January 2005 13:40, Hans Leidekker wrote: > On Wednesday 12 January 2005 22:12, Ferenc Wagner wrote: > > If Paul can use Stefan's patch, then new builds can be > > expected real soon, I guess. > > I've put a couple of new RPMs on my page: >http://mirzam.it.vu.nl/mingw/ OK, I've checked Hans' patches against Stefan's and found differences! I'm not a Windows person, so do these matter? In uuid.c, only the one difference: From Stefan +DEFINE_GUID(IID_IMAPIPropData,0x2031A,0,0,0xC0,0,0,0,0,0,0,0x46); From Hans +DEFINE_OLEGUID(IID_IMAPIPropData,0x2031A,0,0); In the msi.def, quite a few differences, picking one at random From Stefan [EMAIL PROTECTED] From Hans [EMAIL PROTECTED] @8 I don't really want to spend lots of time merging patches, so could one set be defined as "correct", and I'll use them. Cheers, Paul. Cheers, Paul. pgpvWJ0hZaXi7.pgp Description: PGP signature
Re: [AppDB] Now User Preferences is Br0ck. (fix sort of?)
Hey Tony,
On Wed, 12 Jan 2005 20:39:19 -0700, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> > Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
> > allocate 68254 bytes) in /var/www/html/appdb/include/db.php on line 35
> >
> > Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
> > allocate 136 bytes) in Unknown on line 0
Which PHP version are you running (and which one is the live server).
I don't see it happening (4.3.9) and neither does Jonathan (5.x).
> This patch fixes it on my system. the wierd thing is that on my system I have.
>
> define("APPS_DB","apidb");
> and
> define("USERS_DB","apidb");
>
> So why would it make any difference?
This is the most weird thing I've ever seen. Are we overloading the
connection or something. And consider this aswell:
" If a second call is made to mysql_connect() with the same
arguments, no new link will be established, but instead, the link
identifier of the already opened link will be returned."
The only consistent I've seen yet is that it's always this line:
$sStatusMessage .= "Query: ".$sQuery;
Really weird,
Paul
Re: Code cleanup: SHFileOperationW
Joris Huizer wrote: I took out a part of the function SHFileOperationW and put it in a new function - please give any comments: is this the way to make this function more readable you want it? what is a better way of calling such a function? Looks like a step in the right direction. Anything that reduces the number of variables, side effects and conditions in that function would be appreciated. Just be careful to make sure it still passes the test cases written for it... Mike
Re: Code cleanup: SHFileOperationW
Mike McCormack wrote: Joris Huizer wrote: I took out a part of the function SHFileOperationW and put it in a new function - please give any comments: is this the way to make this function more readable you want it? what is a better way of calling such a function? Looks like a step in the right direction. Anything that reduces the number of variables, side effects and conditions in that function would be appreciated. Just be careful to make sure it still passes the test cases written for it... Mike Uhm, trying to be sure all if functionally equivalent ofcourse - but how do I run test cases (I'm using linux here) Joris
Re: WineHQ:winetest: produce valid HTML
On Thursday 13 January 2005 15:23, Paul Millar wrote: > In uuid.c, only the one difference: > From Stefan > +DEFINE_GUID(IID_IMAPIPropData,0x2031A,0,0,0xC0,0,0,0,0,0,0,0x46); > From Hans > +DEFINE_OLEGUID(IID_IMAPIPropData,0x2031A,0,0); Both are correct (the DEFINE_OLEGUID resolves to the former). > In the msi.def, quite a few differences, picking one at random > From Stefan > [EMAIL PROTECTED] > From Hans > [EMAIL PROTECTED] @8 Again, both are OK. -Hans
Re: Code cleanup: SHFileOperationW
Joris Huizer wrote: Uhm, trying to be sure all if functionally equivalent ofcourse - but how do I run test cases (I'm using linux here) Make sure you have a valid .wine on your system, then run: cd dlls/shell32 WINEPREFIX=~/.wine make test You don't need to run them on Windows unless you're modifying the test itself. Somebody else already checked that they pass on various Windows versions. It's also a good idea to try find a program that uses the function and test that too. Mike
Re: The use of a zero flag
On Thu, 13 Jan 2005, Paul Vriens wrote:
[...]
how do you cater for the following in your one-liner:
include/accctrl.h:#define ACTRL_RESERVED 0x
include/accctrl.h:#define ACTRL_DS_OPEN ACTRL_RESERVED
good luck :-)
The previous script doesn't. Handling this is a bit more tricky, mostly
because of sed's restrictions on regular expressions.
Fortunately perl is there to save the day!
There you go:
new=`perl -n -e 'chomp;if (s/^ *# *define *([a-zA-Z_][a-zA-Z0-9_]*) *0(x0+L?)? *\$/\$1/)
{print;print " ";}' include/*.h`
while [ -n "$new" ]
do
new=`echo "$new" | sed -e 's/ $//' -e 's/ NULL / /' -e 's/ /|/g'`
if [ -z "$regexp" ]
then
regexp="$new"
else
regexp="$regexp|$new"
fi
new=`perl -n -e "chomp;if (s/^ *# *define *([a-zA-Z_][a-zA-Z0-9_]*) *($new)
*\\$/\\$1/) {print;print ' ';}" include/*.h`
echo "Synonyms: $new"
done
find . -name "*.[chly]" -print0 | xargs -0 perl -n -e "if (eof) {close ARGV;};if (/&
*($regexp)(?![a-zA-Z0-9_]| ==)/ or /($regexp) *&[^&]/) {print \"\$ARGV:\$.: \$_\";}"
Hopefully it won't be too line wrapped.
And here's the result, with no false positives this time, thanks to
perl's negative lookhead.
./dlls/comctl32/listview.c:6297: if (nColumn == 0 || lpColumn->fmt &
LVCFMT_LEFT)
./dlls/comctl32/pager.c:844: if (!(dwStyle & PGS_HORZ) && !(dwStyle &
PGS_VERT))
./dlls/commdlg/filedlgbrowser.c:320:(wFlags & SBSP_ABSOLUTE) ? "SBSP_ABSOLUTE" :
"SBPS_");
./dlls/dplayx/dplay.c:1164: if( ( dwFlags & DPSET_REMOTE ) &&
./dlls/dplayx/dplay.c:1180: if( dwFlags & DPSET_REMOTE )
./dlls/dplayx/dplay.c:1363: if( ( dwFlags & DPSET_REMOTE ) &&
./dlls/dplayx/dplay.c:1379: if( dwFlags & DPSET_REMOTE )
./dlls/dplayx/dplay.c:2430: if( dwFlags & DPSET_REMOTE )
./dlls/dplayx/dplay.c:2635: if( dwFlags & DPSET_REMOTE )
./dlls/dplayx/dplay.c:3061: if( dwFlags & DPSET_REMOTE )
./dlls/dplayx/dplay.c:3074: if( dwFlags & DPSET_REMOTE )
./dlls/dplayx/dplay.c:3159: if( dwFlags & DPSET_REMOTE )
./dlls/dplayx/dplay.c:3169: if( dwFlags & DPSET_REMOTE )
./dlls/winmm/mciseq/mcimidi.c:1359: if (lpParms->dwAudio &
MCI_SET_AUDIO_ALL)
./dlls/winmm/mciwave/mciwave.c:1233:if (lpParms->dwAudio &
MCI_SET_AUDIO_ALL)
But seriously what would be the best way to fix up dplayx.c?
Not sure, maybe:
if (dwFlags == DPSET_REMOTE)
or
if (!dwFlags)
but I find the latter a bit less clear.
--
Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/
I haven't lost my mind, it's backed up on tape around here somewhere...
Re: Code cleanup: SHFileOperationW
On Thu, 13 Jan 2005 15:12:17 +0100, Joris Huizer wrote:
> I took out a part of the function SHFileOperationW and put it in a new
> function - please give any comments: is this the way to make this
> function more readable you want it? what is a better way of calling such
> a function?
Yes this looks good but for internal functions IMHO it's best to use
GNU style naming, eg:
static int file_operation_delete(...)
{
}
That way it's (A) obvious what's internal and exported and (B) mixtures of
GNU style and Win32 style in the same name are ugly :)
Remember internal functions don't need WINAPI linkage.
Finally be careful with diff, you included some Interlocked* fixes in
there too.
thanks -mike
Re: [LOSTWAGES] Add janitorial task to avoid using strncpy
Mike McCormack wrote:
ChangeLog:
* Add janitorial task to avoid using strncpy
Index: templates/en/janitorial.template
===
RCS file: /home/wine/lostwages/templates/en/janitorial.template,v
retrieving revision 1.61
diff -u -r1.61 janitorial.template
--- templates/en/janitorial.template 11 Jan 2005 20:33:41 - 1.61
+++ templates/en/janitorial.template 13 Jan 2005 15:15:44 -
@@ -7,6 +7,24 @@
Janitor's List), and it's high time that we have one too.
What is there to clean up? Well, lots of things! :)
+ Eliminate uses of strncpy/strncpyW
+
+ strncpy(dst,src,n) has two subtle
+ http://weblogs.asp.net/oldnewthing/archive/2005/01/07.aspx";>
+ problems. The first is that it always fills the whole dst
+ buffer (n characters). The second is that it doesn't always nul
+ terminate the dst buffer that it's filling.
+
+ Wine code should avoid the use of strncpy for these reasons, and instead
+ use lstrcpyA/W or memcpy. You can use the following command to find
+ occurences of strncpy in the Wine source code:
+
+ find . -name \*.c -exec grep strncpy {} \; -ls
+
+ The aim is to make sure that we only copy as many bytes as necessary into
+ the dst buffer, and always nul terminate the buffer when we
+ intended to.
+
Regedit fixes
Regedit lacks a few features. We need to improve regedit to:
Couldn't we just make a sane implementation of strncpy, not adding more
'\0' characters than necessary and making sure the last character is an
'\0'? (untested ofcourse ;))
char *strncpy(char *dst,char *src,int n)
{
int i;
for (i = 0; (dst[i] = src[i]) != '\0' && i < n; i++)
;
/* n - 1 is '\0'; ensures the end of the string is '\0' */
dst[n - 1] = '\0';
}
Now, something like this would at least save us of replacing all
strncpyW, wouldn't it?
regards,
Joris
Re: Code cleanup: SHFileOperationW
Mike Hearn wrote:
Yes this looks good but for internal functions IMHO it's best to use
GNU style naming, eg:
static int file_operation_delete(...)
{
}
SHELL_internal_function() is a better way to go, IMO. It's already the
Wine convention, you can easily locate the function, and it helps make
sure no two functions will be named the same thing. There's no reason
to make a new convention just because you think the old one is "ugly".
Mike
RE: [LOSTWAGES] Add janitorial task to avoid using strncpy
> From: Joris Huizer > > Mike McCormack wrote: > > ChangeLog: > > * Add janitorial task to avoid using strncpy > > Couldn't we just make a sane implementation of strncpy, not > adding more '\0' characters than necessary and making sure > the last character is an '\0'? That sane implementation already exists as lstrcpynA/lstrcpynW in kernel32. Ge van Geldorp.
Re: [LOSTWAGES] Add janitorial task to avoid using strncpy
Ge van Geldorp wrote: From: Joris Huizer Mike McCormack wrote: ChangeLog: * Add janitorial task to avoid using strncpy Couldn't we just make a sane implementation of strncpy, not adding more '\0' characters than necessary and making sure the last character is an '\0'? That sane implementation already exists as lstrcpynA/lstrcpynW in kernel32. Ge van Geldorp. hmm, well, then what more is needed than s/strncpy\(/lstrcpynA/ and s/strncpyW/lstrcpynW and a note for future code .. ?
Re: [LOSTWAGES] Add janitorial task to avoid using strncpy
hmm, well, then what more is needed than s/strncpy\(/lstrcpynA/ and s/strncpyW/lstrcpynW and a note for future code .. ? Yes, my bad. I'll resend the suggestion. Mike
RE: [LOSTWAGES] Add janitorial task to avoid using strncpy
On Thu, 13 Jan 2005, Ge van Geldorp wrote: [...] Couldn't we just make a sane implementation of strncpy, not adding more '\0' characters than necessary and making sure the last character is an '\0'? That sane implementation already exists as lstrcpynA/lstrcpynW in kernel32. Btw, Mike actually wrote: + Wine code should avoid the use of strncpy for these reasons, and instead + use lstrcpyA/W or memcpy. So if lstrcpyA/W and not lstrcpynA/W is really what's wanted then we might want to explain a bit more. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ In a world without fences who needs Gates?
Re: Code cleanup: SHFileOperationW
Mike McCormack wrote:
Mike Hearn wrote:
Yes this looks good but for internal functions IMHO it's best to use
GNU style naming, eg:
static int file_operation_delete(...)
{
}
SHELL_internal_function() is a better way to go, IMO. It's already the
Wine convention, you can easily locate the function, and it helps make
sure no two functions will be named the same thing. There's no reason
to make a new convention just because you think the old one is "ugly".
Mike
Hmm, I see this indeed; should I rename and send again?
The convension seems to be like SHELL_internetFunction(), although there
also seem to be a few SHELL32_* functions
I also saw a few other debugger helper functions for SHFileOperationW,
named debug_shfileops_flags and debug_shfileops_action; is this a
special debugger convension or should those be renamed as well ?
Joris
Re: NOTIFY_PRE and NOTIFY_POST definitions in include files
Francois wrote: > So I would say the correct values are the ones in npapi.h and that > netspi.h should be moved to dlls/mpr which is the only place where it is > used. But this needs a bit more investigation. I agree. I would conjecture that netspi.h is old, and the declarations in it have been superceded by those in npapi.h. For example, the definitions of NOFIYADD, NOTIFYCANCEL, and NOTIFYINFO don't match MSDN: http://msdn.microsoft.com/library/en-us/secauthn/security/notifyadd.asp http://msdn.microsoft.com/library/en-us/secauthn/security/notifycancel.asp http://msdn.microsoft.com/library/en-us/secauthn/security/notifyinfo.asp but those in npapi.h do. The main use of netspi.h seems to be to declare the NPS functions defined in mpr/nps.c. These aren't documented on MSDN, but are exported by Win9x versions of mpr.dll. Anything that doesn't support these functions should be deleted, and since it's not part of the PSDK, making it a private header is fine, or just moving the required declarations to nps.c should be fine too. --Juan __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo
Re: Code cleanup: SHFileOperationW
Joris Huizer wrote: Hmm, I see this indeed; should I rename and send again? The convension seems to be like SHELL_internetFunction(), although there also seem to be a few SHELL32_* functions Up to you. I also saw a few other debugger helper functions for SHFileOperationW, named debug_shfileops_flags and debug_shfileops_action; is this a special debugger convension or should those be renamed as well ? Yeah, that was done by me in an attempt to copy the debugstr_w() and debugstd_guid() debugging helper functions, so it didn't follow the SHELL_ convention. Mike
Re: [LOSTWAGES] Add janitorial task to avoid using strncpy
Joris Huizer <[EMAIL PROTECTED]> writes: > hmm, well, then what more is needed than s/strncpy\(/lstrcpynA/ and > s/strncpyW/lstrcpynW and a note for future code .. ? A careful review of the code to ensure that lstrcpyn semantics are really what we want. In several cases we know that we are copying less than the full string, and in that case we have to use memcpy instead, lstrcpyn won't do the right thing. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Code cleanup: SHFileOperationW
On Fri, 14 Jan 2005 01:57:29 +0900, Mike McCormack wrote: > SHELL_internal_function() is a better way to go, IMO. It's already the > Wine convention, you can easily locate the function, and it helps make > sure no two functions will be named the same thing. There's no reason > to make a new convention just because you think the old one is "ugly". Given the only reason we do this anymore is for etags/ctags I think I will start investigating whether it's possible for a tags implementation to restrict scope in tag searches. Because yes I do think the DLLNAME_ prefix we have all over the place is ugly and unnecessary ...
[DPLAYX] Get rid of check for DPSET_REMOTE in dplayx.c
Hi,
as DPSET_REMOTE is 0 we cannot check for it, like it's currently done in
dplayx.c:
if( dwFlags & DPSET_REMOTE )
we have to use some other method. As DPSET_REMOTE and DPSET_LOCAL (which
is 1) are mutually exclusive we could do:
if (!(dwFlags & DPSET_LOCAL))
{
}
or
if (dwFlags & DPSET_LOCAL)
{
}
else /* DPSET_REMOTE */
{
}
The attached patch gets rid of the afore mentioned wrong checks.
Remember that because of the changes the code-path changes as well. We
now get into places where we 'never' went before.
Patch is only compile tested and I changed some of the coding-style.
Any comment is welcome. (I'm learning).
Cheers,
Paul.
Index: dlls/dplayx/dplay.c
===
RCS file: /home/wine/wine/dlls/dplayx/dplay.c,v
retrieving revision 1.54
diff -u -r1.54 dplay.c
--- dlls/dplayx/dplay.c 7 Jan 2005 15:40:09 - 1.54
+++ dlls/dplayx/dplay.c 13 Jan 2005 16:03:15 -
@@ -1153,21 +1153,23 @@
LPVOID lpData, DWORD dwDataSize )
{
/* Clear out the data with this player */
- if( ( dwFlags & DPSET_LOCAL ) &&
- ( lpGData->dwLocalDataSize != 0 )
-)
+ if (dwFlags & DPSET_LOCAL)
{
-HeapFree( GetProcessHeap(), 0, lpGData->lpLocalData );
-lpGData->lpLocalData = NULL;
-lpGData->dwLocalDataSize = 0;
+if (lpGData->dwLocalDataSize != 0)
+{
+ HeapFree( GetProcessHeap(), 0, lpGData->lpLocalData );
+ lpGData->lpLocalData = NULL;
+ lpGData->dwLocalDataSize = 0;
+}
}
- if( ( dwFlags & DPSET_REMOTE ) &&
- ( lpGData->dwRemoteDataSize != 0 )
-)
+ else
{
-HeapFree( GetProcessHeap(), 0, lpGData->lpRemoteData );
-lpGData->lpRemoteData = NULL;
-lpGData->dwRemoteDataSize = 0;
+if (lpGData->dwRemoteDataSize != 0)
+{
+ HeapFree( GetProcessHeap(), 0, lpGData->lpRemoteData );
+ lpGData->lpRemoteData = NULL;
+ lpGData->dwRemoteDataSize = 0;
+}
}
/* Reallocate for new data */
@@ -1177,17 +1179,16 @@
sizeof( dwDataSize ) );
CopyMemory( lpNewData, lpData, dwDataSize );
-if( dwFlags & DPSET_REMOTE )
-{
- lpGData->lpRemoteData = lpNewData;
- lpGData->dwRemoteDataSize = dwDataSize;
-}
-
-if( dwFlags & DPSET_LOCAL )
+if (dwFlags & DPSET_LOCAL)
{
lpGData->lpLocalData = lpData;
lpGData->dwLocalDataSize = dwDataSize;
}
+else
+{
+ lpGData->lpRemoteData = lpNewData;
+ lpGData->dwRemoteDataSize = dwDataSize;
+}
}
}
@@ -1352,21 +1353,23 @@
LPVOID lpData, DWORD dwDataSize )
{
/* Clear out the data with this player */
- if( ( dwFlags & DPSET_LOCAL ) &&
- ( lpPData->dwLocalDataSize != 0 )
-)
+ if (dwFlags & DPSET_LOCAL)
{
-HeapFree( GetProcessHeap(), 0, lpPData->lpLocalData );
-lpPData->lpLocalData = NULL;
-lpPData->dwLocalDataSize = 0;
+if (lpPData->dwLocalDataSize != 0)
+{
+ HeapFree( GetProcessHeap(), 0, lpPData->lpLocalData );
+ lpPData->lpLocalData = NULL;
+ lpPData->dwLocalDataSize = 0;
+}
}
- if( ( dwFlags & DPSET_REMOTE ) &&
- ( lpPData->dwRemoteDataSize != 0 )
-)
+ else
{
-HeapFree( GetProcessHeap(), 0, lpPData->lpRemoteData );
-lpPData->lpRemoteData = NULL;
-lpPData->dwRemoteDataSize = 0;
+if (lpPData->dwRemoteDataSize != 0)
+{
+ HeapFree( GetProcessHeap(), 0, lpPData->lpRemoteData );
+ lpPData->lpRemoteData = NULL;
+ lpPData->dwRemoteDataSize = 0;
+}
}
/* Reallocate for new data */
@@ -1376,17 +1379,17 @@
sizeof( dwDataSize ) );
CopyMemory( lpNewData, lpData, dwDataSize );
-if( dwFlags & DPSET_REMOTE )
+if (dwFlags & DPSET_LOCAL)
+{
+ lpPData->lpLocalData = lpData;
+ lpPData->dwLocalDataSize = dwDataSize;
+}
+else
{
lpPData->lpRemoteData = lpNewData;
lpPData->dwRemoteDataSize = dwDataSize;
}
-if( dwFlags & DPSET_LOCAL )
-{
- lpPData->lpLocalData = lpData;
- lpPData->dwLocalDataSize = dwDataSize;
-}
}
}
@@ -2427,21 +2430,15 @@
}
/* How much buffer is required? */
- if( dwFlags & DPSET_REMOTE )
- {
-dwRequiredBufferSize = lpGData->dwRemoteDataSize;
-lpCopyDataFrom = lpGData->lpRemoteData;
- }
- else if( dwFlags & DPSET_LOCAL )
+ if (dwFlags & DPSET_LOCAL)
{
dwRequiredBufferSize = lpGData->dwLocalDataSize;
lpCopyDataFrom = lpGData->lpLocalData;
}
else
{
-ERR( "Neither local or remote data requested!?!\n" );
-dwRequiredBufferSize = 0;
-lpCopyDataFrom = NULL;
+dwRequiredBufferSize = lpGData->dwRemoteDataSize;
+lpCopyDataFrom = lpGData->lpRemoteData;
}
/* Is the user requesting to know how big a buffer is required? */
@@ -2632,21 +2629,15 @@
}
/* How much buffer is required? */
- if( dwFlags & DPSET_REMOTE )
- {
-dwRequiredBufferSize = lpPList->
Running dxdiag
Hi, I was trying to run dxdiag (just for the fun of it). Dxdiag complains that it cannot find any dll. This is correct because what it does is check the directories in the "Path". The dll's are of course not present on a clean install as all are builtin. Loading a dll takes care of this by checking the DllOverrides and acts according to that if it cannot find the dll. How can we act on an app which checks for a 'physical' presence of a dll? For now I did 'ln -s /usr/local/lib/wine/ddraw.dll.so ddraw.dll' to get around this. This is of course not very flexible. Any ideas? Or will any solution yield in a performance drop as we have to do some extra checks? Paul.
Q: porting driver for USB scanner - where to start?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! I want to write a linux driver for my USB scanner which is currently not yet supported by sane. So I wonder where to start; where do I find detailed information about the Windows driver interface, esp. for USB scanners. I want to know which interface a driver has to offer to Windows and which functionality the API has to offer. Thanks in advance for any help. - -- Heiko Nardmann -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB5kmfpm53PRScYygRAh08AJ9oT68jQ0TKuikBFgJN1HG9EqjW2gCfbk9B Tndu1Nin8Z6DZQ/yg3+GEjc= =Dvvb -END PGP SIGNATURE-
Re: [AppDB] new fix for preferences
Good job guys. That was a tricky one to figure out. I'm surprised we haven't
run into it before.
Chris
>
> From: Jonathan Ernst <[EMAIL PROTECTED]>
> Date: 2005/01/13 Thu PM 02:16:51 EST
> To: [EMAIL PROTECTED]
> Subject: [AppDB] new fix for preferences
>
>
After 4 hours of hacking with Paul and Tony, we finally found a solution that
avoids using the old query_userdb() function.
Changelog:
- fix preferences.php without using query_userdb
Files changed:
- preferences.php
- include/db.php
Index: preferences.php
===
RCS file: /home/wine/appdb/preferences.php,v
retrieving revision 1.14
diff -u -r1.14 preferences.php
--- preferences.php 13 Jan 2005 05:37:52 - 1.14
+++ preferences.php 13 Jan 2005 19:12:17 -
@@ -17,8 +17,8 @@
function build_prefs_list()
{
-$result = query_userdb("SELECT * FROM prefs_list ORDER BY id");
-while($r = mysql_fetch_object($result))
+$result = query_appdb("SELECT * FROM prefs_list ORDER BY id");
+while($result && $r = mysql_fetch_object($result))
{
//skip admin options
//TODO: add a field to prefs_list to flag the user level for the pref
Index: include/db.php
===
RCS file: /home/wine/appdb/include/db.php,v
retrieving revision 1.10
diff -u -r1.10 db.php
--- include/db.php 13 Jan 2005 05:37:52 - 1.10
+++ include/db.php 13 Jan 2005 19:12:26 -
@@ -1,43 +1,31 @@
Database Error!";
-$sStatusMessage .= "Query: ".$sQuery;
+$sStatusMessage .= "Query: ".$sQuery."";
$sStatusMessage .= $sComment ? $sComment."" : "";
$sStatusMessage .= mysql_error()."\n";
addmsg($sStatusMessage, "red");
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Q: porting driver for USB scanner - where to start?
> I want to write a linux driver for my USB scanner which is currently not > yet supported by sane. So I wonder where to start; where do I find detailed > information about the Windows driver interface, esp. for USB scanners. I > want to know which interface a driver has to offer to Windows and which > functionality the API has to offer. www.msdn.com might be useful I guess.
COM inheritance Q
Hiya,
In the wined3d code I have, for example, a class surface which inherits a
lot of methods of Resource. Most of these methods can be called as-is, and I
have code which looks like:
HRESULT WINAPI IWineD3DSurfaceImpl_GetParent(IWineD3DSurface *iface,
IUnknown **pParent) {
return IWineD3DResource_GetParent((IWineD3DResource *)iface, pParent);
}
Great idea but this fails:
IWineD3DResource_GetParent is a macro:
#define IWineD3DSurface_GetParent(p,a)
(p)->lpVtbl->GetParent(p,a)
So we then go iface->lpVtbl->GetTable. Since iface is a surface, once cast
to a resource its GetParent is in the same place in the table... Hence the
call ends up being effectively
HRESULT WINAPI IWineD3DSurfaceImpl_GetParent(IWineD3DSurface *iface,
IUnknown **pParent) {
return IWineD3DSurfaceImpl_GetParent (iface, pParent);
}
Whats the solution?
In d3d8 I would have coded IWineD3DSurfaceImpl_GetParent as
IWineD3DResourceImpl_GetParent(iface, pParent) because the Impl versions
were prototyped - Is this the only way to solve this?
Jason
Re: Code cleanup: SHFileOperationW
Mike McCormack wrote:
Mike Hearn wrote:
Yes this looks good but for internal functions IMHO it's best to use
GNU style naming, eg:
static int file_operation_delete(...)
{
}
SHELL_internal_function() is a better way to go, IMO. It's already
the Wine convention,
An ugly convention. SHOUTING is not nice to read when using written
communications and it is not nice to read in code.
you can easily locate the function,
This convention is typically only used for static functions. You should
know if you come across a function named like that then all you have to
do is use your editor's search function to find the function in the file
you're working in.
and it helps make sure no two functions will be named the same thing.
What is the problem with that?
There's no reason to make a new convention just because you think the
old one is "ugly".
If the code makes me want to scratch my eyes out, I'm not likely to want
to hack on it.
Rob
Re: COM inheritance Q
Ann and Jason Edmeades wrote:
Hiya,
In the wined3d code I have, for example, a class surface which inherits a
lot of methods of Resource. Most of these methods can be called as-is, and I
have code which looks like:
HRESULT WINAPI IWineD3DSurfaceImpl_GetParent(IWineD3DSurface *iface,
IUnknown **pParent) {
return IWineD3DResource_GetParent((IWineD3DResource *)iface, pParent);
}
Great idea but this fails:
IWineD3DResource_GetParent is a macro:
#define IWineD3DSurface_GetParent(p,a)
(p)->lpVtbl->GetParent(p,a)
So we then go iface->lpVtbl->GetTable. Since iface is a surface, once cast
to a resource its GetParent is in the same place in the table... Hence the
call ends up being effectively
HRESULT WINAPI IWineD3DSurfaceImpl_GetParent(IWineD3DSurface *iface,
IUnknown **pParent) {
return IWineD3DSurfaceImpl_GetParent (iface, pParent);
}
Whats the solution?
In d3d8 I would have coded IWineD3DSurfaceImpl_GetParent as
IWineD3DResourceImpl_GetParent(iface, pParent) because the Impl versions
were prototyped - Is this the only way to solve this?
I don't think I've got enough information to answer you correctly. Is
this a multiple inheritance problem? I.e. does the object implement both
IWineD3DSurface and IWineD3DResource and not have one directly
inheriting from the other?
Rob
heapalloc woes..
Hi, I've been doing some DirectX work with Jason and have come across a problem? with heapalloc. As soon as my system ram maxes out heapalloc fails, even though Linux is using some ram for cache and only 500k of swap is used. Wine is using <300Mb I ahve 512Mb ram and 512 swap. I've written a small test app using malloc to make sure swap is working and I can allocate well over 700Mb of ram without any problems. Should I be using something other than heapalloc or is this a 'wine' problem? ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Re: COM inheritance Q
On Thursday 13 January 2005 21:43, Robert Shearman wrote:
> Ann and Jason Edmeades wrote:
> >Hiya,
> >
> >In the wined3d code I have, for example, a class surface which inherits a
> >lot of methods of Resource. Most of these methods can be called as-is, and
> > I have code which looks like:
> >
> >HRESULT WINAPI IWineD3DSurfaceImpl_GetParent(IWineD3DSurface *iface,
> >IUnknown **pParent) {
> >return IWineD3DResource_GetParent((IWineD3DResource *)iface, pParent);
> >}
> >
> >Great idea but this fails:
> >
> >IWineD3DResource_GetParent is a macro:
> >#define IWineD3DSurface_GetParent(p,a)
> >(p)->lpVtbl->GetParent(p,a)
> >
> >So we then go iface->lpVtbl->GetTable. Since iface is a surface, once cast
> >to a resource its GetParent is in the same place in the table... Hence the
> >call ends up being effectively
> >
> >HRESULT WINAPI IWineD3DSurfaceImpl_GetParent(IWineD3DSurface *iface,
> >IUnknown **pParent) {
> >return IWineD3DSurfaceImpl_GetParent (iface, pParent);
> >}
> >
> >Whats the solution?
> >
> >In d3d8 I would have coded IWineD3DSurfaceImpl_GetParent as
> >IWineD3DResourceImpl_GetParent(iface, pParent) because the Impl versions
> >were prototyped - Is this the only way to solve this?
>
> I don't think I've got enough information to answer you correctly. Is
> this a multiple inheritance problem? I.e. does the object implement both
> IWineD3DSurface and IWineD3DResource and not have one directly
> inheriting from the other?
>
> Rob
Hi
Jason seems to have:
- IWineD3DSurface inherits from IWineD3DResource
- IWineD3DResource inherits from IUnknown
Jason, why IWineD3DSurface inherits from IWineD3DResource ?
as D3DSurfaces dont inherits from Ressources
(cf
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/directx/graphics/reference/d3d/interfaces/idirect3dsurface9/_idirect3dsurface9.asp)
But for me the only (proper) way to handle your problem is to do as done in
d3d8 code
Regards,
Raphael
pgphiyMmWunPr.pgp
Description: PGP signature
RE: COM inheritance Q
>>I have code which looks like:
>>
>>HRESULT WINAPI IWineD3DSurfaceImpl_GetParent(IWineD3DSurface *iface,
>>IUnknown **pParent) {
>>return IWineD3DResource_GetParent((IWineD3DResource *)iface, pParent);
>>}
>>
>>IWineD3DResource_GetParent is a macro:
>>#define IWineD3DSurface_GetParent(p,a)
>>(p)->lpVtbl->GetParent(p,a)
>>
>>So we then go iface->lpVtbl->GetTable. Since iface is a surface, once cast
>>to a resource its GetParent is in the same place in the table... Hence the
>>call ends up being effectively
>>
>>HRESULT WINAPI IWineD3DSurfaceImpl_GetParent(IWineD3DSurface *iface,
>>IUnknown **pParent) {
>>return IWineD3DSurfaceImpl_GetParent (iface, pParent);
>>}
>>
>>Whats the solution?
>>
>>In d3d8 I would have coded IWineD3DSurfaceImpl_GetParent as
>>IWineD3DResourceImpl_GetParent(iface, pParent) because the Impl versions
>>were prototyped - Is this the only way to solve this?
>>
>>
>I don't think I've got enough information to answer you correctly. Is
>this a multiple inheritance problem? I.e. does the object implement both
>IWineD3DSurface and IWineD3DResource and not have one directly
>inheriting from the other?
No, a single inheritance issue. Let me try to explain...
Resource is defined as having functions A,B,C and its vtbl is {a,b,c}
Surface is defined as having functions A,B,C,D,E,F and its vtbl is
{a,b,c,d,e,f}. Note 'a' is an entrypoint to surface not resource, since that
wasn't possible (see another thread a long time ago!)...
So in surface_A I want to call resource_a, and code it as expected, ie
Resource_a((resource) iface, parms)... But the entrypoint, regardless of the
casting, is got from the first entry in the vtbl, which (again, regardless
of the casting) is surfaces a function...
Better?
Jason
RE: COM inheritance Q
>Jason seems to have:
>- IWineD3DSurface inherits from IWineD3DResource
>- IWineD3DResource inherits from IUnknown
Yep...
>Jason, why IWineD3DSurface inherits from IWineD3DResource ?
Well wine has
/***
**
* IDirect3DSurface9 interface
*/
#define INTERFACE IDirect3DSurface9
DECLARE_INTERFACE_(IDirect3DSurface9,IDirect3DResource9)
{
and the dxsdk
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/
directx/graphics/reference/d3d/interfaces/idirect3dsurface9/_idirect3dsurfac
e9.asp
states
Inherits from IDirect3DResource9
(See the table)
I think the sdk includes also do it this way
Jason
Re: COM inheritance Q
On Thu, 13 Jan 2005 20:33:10 +, Ann and Jason Edmeades wrote:
> Whats the solution?
>
> In d3d8 I would have coded IWineD3DSurfaceImpl_GetParent as
> IWineD3DResourceImpl_GetParent(iface, pParent) because the Impl versions
> were prototyped - Is this the only way to solve this?
I'm kind of confused too but it seems you really want two interfaces
that inherit from each other here rather than having two separate
interfaces that happen to have the same name.
So, IWineD3DSurface should inherit from IWineD3DResource which in
turn should inherit from IUnknown. Then you fill out the vtable
appropriately for overrides. Isn't object orientation in C fun :)
typedef struct
{
IWineD3DSurfaceVtbl *lpVtbl;
DWORD refcount;
} WineD3DSurface;
static IWineD3DSurfaceVtbl SurfaceVtbl = {
/* IUnknown methods are reimplemented per object here but you could be
cleverer */
WineD3DSurface_QueryInterface,
WineD3DSurface_AddRef,
WineD3DSurface_Release,
/* Now for the Resource methods */
WineD3DResource_XXX,
WineD3DResource_YYY,
/* Now for the Surface methods */
WineD3DSurface_AAA,
WineD3DSurface_BBB
};
static WineD3DSurface *WineD3DSurface_Create()
{
WineD3DSurface *obj = HeapAlloc(GetProcessHeap(), 0,
sizeof(WineD3DSurface));
obj->lpVtbl = &SurfaceVtbl;
}
Of course for object orientation to be *useful* like that, the WineD3DResource
methods
have to be able to cast the incoming object ptr to a WineD3DResource object, so
you need to use struct inheritance like so:
struct WineD3DSurface
{
WineD3DResource parent; /* note the lack of an asterisk: this embeds a
copy of the struct so casting works, not a pointer */
/* add your additional fields here ... now casting a Surface to a Resource
works */
}
Remember that lpVtbl can go anywhere :)
thanks -mike
Re: COM inheritance Q
On Thursday 13 January 2005 22:09, you wrote:
> >Jason seems to have:
> >- IWineD3DSurface inherits from IWineD3DResource
> >- IWineD3DResource inherits from IUnknown
>
> Yep...
>
> >Jason, why IWineD3DSurface inherits from IWineD3DResource ?
>
> Well wine has
>
> /**
>* **
> * IDirect3DSurface9 interface
> */
> #define INTERFACE IDirect3DSurface9
> DECLARE_INTERFACE_(IDirect3DSurface9,IDirect3DResource9)
> {
>
> and the dxsdk
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c
>/
> directx/graphics/reference/d3d/interfaces/idirect3dsurface9/_idirect3dsurfa
>c e9.asp
>
> states
>
> Inherits from IDirect3DResource9
>
> (See the table)
>
> I think the sdk includes also do it this way
>
> Jason
Well my SDK headers are out-dated :(
Regards,
Raphael
pgpnmGMLgO6rR.pgp
Description: PGP signature
Re: COM inheritance Q
Ann and Jason Edmeades wrote:
I have code which looks like:
HRESULT WINAPI IWineD3DSurfaceImpl_GetParent(IWineD3DSurface *iface,
IUnknown **pParent) {
return IWineD3DResource_GetParent((IWineD3DResource *)iface, pParent);
}
IWineD3DResource_GetParent is a macro:
#define IWineD3DSurface_GetParent(p,a)
(p)->lpVtbl->GetParent(p,a)
So we then go iface->lpVtbl->GetTable. Since iface is a surface, once cast
to a resource its GetParent is in the same place in the table... Hence the
call ends up being effectively
HRESULT WINAPI IWineD3DSurfaceImpl_GetParent(IWineD3DSurface *iface,
IUnknown **pParent) {
return IWineD3DSurfaceImpl_GetParent (iface, pParent);
}
Whats the solution?
In d3d8 I would have coded IWineD3DSurfaceImpl_GetParent as
IWineD3DResourceImpl_GetParent(iface, pParent) because the Impl versions
were prototyped - Is this the only way to solve this?
I don't think I've got enough information to answer you correctly. Is
this a multiple inheritance problem? I.e. does the object implement both
IWineD3DSurface and IWineD3DResource and not have one directly
inheriting from the other?
No, a single inheritance issue. Let me try to explain...
Resource is defined as having functions A,B,C and its vtbl is {a,b,c}
Surface is defined as having functions A,B,C,D,E,F and its vtbl is
{a,b,c,d,e,f}. Note 'a' is an entrypoint to surface not resource, since that
wasn't possible (see another thread a long time ago!)...
So in surface_A I want to call resource_a, and code it as expected, ie
Resource_a((resource) iface, parms)... But the entrypoint, regardless of the
casting, is got from the first entry in the vtbl, which (again, regardless
of the casting) is surfaces a function...
Better?
In that case, yes, you will have to add a prototype for the base
implementation and call it from the inheriting object. You have to tell
the compiler where the implementation is somewhere along the line, but
putting the base implementation directly into the vtable will result in
conflicting types, so adding a new function for the inheriting object is
the best way to do it.
This would be slightly easier in C++.
Rob
Re: COM inheritance Q
Mike Hearn wrote:
On Thu, 13 Jan 2005 20:33:10 +, Ann and Jason Edmeades wrote:
Whats the solution?
In d3d8 I would have coded IWineD3DSurfaceImpl_GetParent as
IWineD3DResourceImpl_GetParent(iface, pParent) because the Impl versions
were prototyped - Is this the only way to solve this?
I'm kind of confused too but it seems you really want two interfaces
that inherit from each other here rather than having two separate
interfaces that happen to have the same name.
So, IWineD3DSurface should inherit from IWineD3DResource which in
turn should inherit from IUnknown. Then you fill out the vtable
appropriately for overrides. Isn't object orientation in C fun :)
typedef struct
{
IWineD3DSurfaceVtbl *lpVtbl;
DWORD refcount;
} WineD3DSurface;
static IWineD3DSurfaceVtbl SurfaceVtbl = {
/* IUnknown methods are reimplemented per object here but you could be
cleverer */
WineD3DSurface_QueryInterface,
WineD3DSurface_AddRef,
WineD3DSurface_Release,
/* Now for the Resource methods */
WineD3DResource_XXX,
WineD3DResource_YYY,
/* Now for the Surface methods */
WineD3DSurface_AAA,
WineD3DSurface_BBB
};
But you'll get a warning because the WineD3DResource functions will take
a different type iface variable as their first parameter. You could cast
it to the correct type, but you'll lose all type checking on the
function and I wouldn't recommend it.
Rob
RE: COM inheritance Q
>So, IWineD3DSurface should inherit from IWineD3DResource which in
>turn should inherit from IUnknown. Then you fill out the vtable
>appropriately for overrides. Isn't object orientation in C fun :)
>
>typedef struct
>{
> IWineD3DSurfaceVtbl *lpVtbl;
> DWORD refcount;
>
>} WineD3DSurface;
>
>static IWineD3DSurfaceVtbl SurfaceVtbl = {
> /* IUnknown methods are reimplemented per object here but you could be
cleverer */
> WineD3DSurface_QueryInterface,
> WineD3DSurface_AddRef,
> WineD3DSurface_Release,
>
> /* Now for the Resource methods */
> WineD3DResource_XXX,
> WineD3DResource_YYY,
>
> /* Now for the Surface methods */
> WineD3DSurface_AAA,
> WineD3DSurface_BBB
>};
>
>
That's what I tried originally, but C cant do it if surface and resource are
in different files (That was exactly a thread on wined3d because I hit this
and was told there was no way around it).
Also, the Surface XXX may want to override the Resource XXX or it may be
happy just calling it...
I'll go for the prototypes/calling directly, as per d3d8 - I've used my
editor macro skills to convert the interface definition into prototypes
fairly quickly!
And yes... C++ would be a lot easier, and if you knew me you'd know how hard
it is saying that (I hate C++ compared to C, Java etc).
Jason
Re: COM inheritance Q
On Thu, 13 Jan 2005 15:21:27 -0600, Robert Shearman wrote: > But you'll get a warning because the WineD3DResource functions will take > a different type iface variable as their first parameter. You could cast > it to the correct type, but you'll lose all type checking on the > function and I wouldn't recommend it. Hmm, true, how annoying. Still, I think relaxing type safety in this instance is better than lots of relay functions that just rename the function especially in high performance code like Direct3D. thanks -mike
Re: [AppDB] new fix for preferences
Hey, On Thu, 13 Jan 2005 14:43:49 -0500, Chris Morgan <[EMAIL PROTECTED]> wrote: > Good job guys. That was a tricky one to figure out. Yes it was (all honor to Tony and Jonathan for finding it). The memory alloc problems were caused by addmsg() calling itself recursively trying to insert a message, failing, and trying to insert a message again (trough query_error()). And those failures were caused because the connection to mysql was changed to use another database (the bugzilla db, hence the failure just after using a bugzilla function). And that was caused because although we defined a different connection resource internally the same handle was used (as descriped by the PHP manual) Now we are reselecting the database with each call to the query functions. This is still not completely a clean solution. As this will send an additional query to mysql with each query. I will try something with Tony tomorrow to get it completely clean. We also need to protect addmsg calling itself recursively. I was thinking of checking if it send out the same message already and if so exit;. Another solution would be to not use quer_appdb() but just mysql_query(). What do you think? Paul
Re: Q: porting driver for USB scanner - where to start?
On Thu, 13 Jan 2005, Heiko Nardmann wrote: [...] I want to write a linux driver for my USB scanner which is currently not yet supported by sane. So I wonder where to start; where do I find detailed information about the Windows driver interface, esp. for USB scanners. I want to know which interface a driver has to offer to Windows and which functionality the API has to offer. Well I think the right solution would be to add support for your scanner to SANE. Then Wine should be able to use it using the twain dll (see dlls/twain) which acts as a bridge to SANE. Interfacing directly with the scanner might work using Wine's brand new and very incomplete USB interface (I believe part of it is in setupapi) but that would probably be more code and you would still end up writing what is essentially a driver. In other words in either case you will probably need the hardware specifications. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U
Re: Running dxdiag
On Thu, 13 Jan 2005 19:56:45 +0100, Paul Vriens wrote: > How can we act on an app which checks for a 'physical' presence of a > dll? Somebody needs to write a program that dumps the NT headers of each winelib DLL to the appropriate place in the virtual drive C when it's first created (in wineprefixcreate). It's been talked about before, Andi even did it once but then his patch was eaten by wayward hardware before it could be submitted. So we really need somebody to pick this project up and run with it. Dumping the headers is necessary for stupid installers that map DLL files manually and rummage around in the headers to figure out versions and stuff ... simply having an empty file isn't enough for all of them I'm afraid :( thanks -mike
Re: Code cleanup: SHFileOperationW
Robert Shearman wrote: If the code makes me want to scratch my eyes out, I'm not likely to want to hack on it. If you want to modify piece of code X, then code in the same style as piece of code X. Then piece of code X will all be written in the same coding style, and will be less eye-scratchy. Use a prefix for your functions to make it easier for people that didn't write the code to find, and to avoid duplicate elf symbols for non static functions. If you don't like SHELL_ then use shell_. There's already a mismash of coding styles in Wine, and the last thing we need is more. Mike
Re: Janitorial : add missing declarations ( #3 )
"Rémi Assailly" <[EMAIL PROTECTED]> wrote: > diff -u dlls/x11drv/x11drv_main.c dlls/x11drv/x11drv_main.c > --- dlls/x11drv/x11drv_main.c 2004-12-08 18:27:53.0 +0100 > +++ dlls/x11drv/x11drv_main.c 2005-01-12 21:23:02.0 +0100 > @@ -119,6 +119,8 @@ > #define IS_OPTION_FALSE(ch) \ > ((ch) == 'n' || (ch) == 'N' || (ch) == 'f' || (ch) == 'F' || (ch) == '0') > > +BOOL WINAPI DllMain( HINSTANCE hinst, DWORD reason, LPVOID reserved ); This one should not be needed. -- Dmitry.
Re: Keyboard+Ukrainian
"Oleh R. Nykyforchyn" <[EMAIL PROTECTED]> wrote: > I propose two patches to Wine20050111 (sorry for not using CVS, but I have > rather > slow dialup connection). First is more or less obvious: current cp_20866.c > page > includes only Russian KOI8-R codes and is insufficient for Ukrainian and > Byelarussian users. > It is easy to add four Ukrainian pairs and one Byelarussian pair of letters > (in fact, > move to KOI8-RU). I patched the Perl script an regenerated cp_20866.c: You can't do that. Windows has a distinct code page for Ukrainian and Byelarussian, it's 21866. > Second proposal is more complicated. I have four XKB groups in my X.org > (Latin + 3 cyrillic encodings), and, moreover, use overlays to switch > between Ukrainian and Russian. This approach is typical among Cyrillic > Linux users. Of course, wine cannot handle my case, so I partially rewrote > keyboard.c to take care of groups and overlays switching if XKB is present. > Now You can have four independent layouts up to four shift levels in each. > If XKB is absent, wine will behave as before. Driver will switch internal > XKB group counter each time when looked up symbol doesn't match previously > built tables. If this doesn't help, the whole layout ONLY FOR THIS GROUP > (to save time) will be refreshed. The real fix for your problem is to add a proper support for keyboard layouts, and switch internal x11drv layout on an appropriate X event. -- Dmitry.
Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]
Jeremy White wrote: Fyi, I spent a great deal of time this past fall exploring Wine scheduling issues, and I thought I would post what I learned. The most critical point is Wine was pretty badly broken; it simply had a number of flaws in how scheduling was done. First, the winmm timer, used by a lot of programs, was pretty awful. That has now been fixed, and I believe that it now works correctly. Second, we did not synchronize Wine message times with X11 message times properly. Fixing that resolved some issues with Photoshop (and given that Ove reworked that patch into WineX the same day I submitted it, I'd guess it fixed some games too ). Third, Wine did not yield the processor properly at points where Windows does, including Sleep(0) and certain event conditions. That's now been (mostly) fixed, I think. Fourth, the Wine server had an issue with the way it managed it request queues. To be honest, I don't understand this bug or the fix; all I know is that Mike McCormack figured this one out and posted a magic fix. This was, I believe, the primary reason that the wineserver would chew 100% cpu with iTunes. Beyond that, there are a number of ways that Wine 'gets lucky' and Just Works (TM) works on the Linux scheduler, in ways that we couldn't have asked for. First, because many Wine calls resolve into a wineserver call, and a wineserver call involves a write to a pipe, we potentially risk yielding the processor far more often in Wine that a Windows program would 'naturally' do so on Windows; opening us to horrendous timing bugs. However, in practice, because the Wine server often handles requests within a single quanta, and because waiting on a pipe with data gets a priority boost in Linux, the net effect is what Wine wants. (Thread A makes a request, yields to the Wine server who gets in ahead of all other threads, does the requests, sends the response back, and Thread A regains control before any other Wine thread because it got a priority boost). An excellent investigation and summary, thanks! The situation was worse than I anticipated. Thankfully it looks like you're not track. Second, the new 2.6 average time quanta of 100 ms is comparable to the observed Windows quanta of 115 ms (I may have that wrong, but I recall they were quite close), although the old, much smaller time quanta masked a number of Wine scheduling problems. But, in theory, having this longer time quanta should let us better replicate Windows scheduling behavior. Actually this wont help you. The more frequent round robinning of tasks with shorter timeslices blurs any priority differences. With longer timeslices all you'll get is "resonance" However, we still have some issues. First, the problem with thread priorities still remains an issue. A non zero number of important applications rely on Windows priorities to change timing behavior to make their applications run properly. ([editors note: imho, these are poorly written apps, but we have to support them as they are; wishing that MS would rewrite PowerPoint to my spec is amongst the most futile things I can imagine]). There is a patch Mike worked up which makes a theoretical improvement to the Wine server (pull requests from its queue in thread priority order), but we have no evidence that change makes any difference, and Mike backed away from it when he found the afore mentioned 'correct' fix. Nonetheless, I think it is conceptually 'right', so we probably should bug Mike into redoing that patch. I've played with a number of artificial ways to try to replicate this within Wine, and have come up with a few compromises, but nothing works perfectly (or, more importantly, worked up nothing that Alexandre would apply ). If you do try to exactly mirror Windows priorities, for example (running as root, say), you run into issues where the wineserver gets starved and Wine stops functioning. Candidly, that's where I'm stuck. I'm going to revisit a few of my 'problem' apps hopefully sometime this year and see if I can cobble together a hack that works best. Ove, I haven't tried the signalling approach; that seems like an interesting idea. Sadly, short of asking the Linux guys to rewrite the Linux kernel scheduler to exactly mimic Windows behavior, I'm not really sure if there is a lot we can do to get this exactly right. Well the scheduler is not going to be rewritten any time soon (trust me, I've tried :P). Tell me what remaining requirements your threads have that you are unable to achieve at the moment and I'll see if I can help with my understanding of the priority system as it is, in a generic way that hopefully will work across scheduler designs. Cheers, Con signature.asc Description: OpenPGP digital signature
Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]
Well the scheduler is not going to be rewritten any time soon (trust me, I've tried :P). Tell me what remaining requirements your threads have that you are unable to achieve at the moment and I'll see if I can help with my understanding of the priority system as it is, in a generic way that hopefully will work across scheduler designs. What!?!?! The Linux Kernel schedulor won't be rewritten to the exact demands of Wine! Shocking! At this point, I think the only glaring hole we have is the issue of thread priorities. That seems to be a capability we simply can't accurately replicate in Wine. My hope is that if we can somehow mock that up (or address the few dodgy cases where it's a problem), we won't face any other timing issues. From there, I think the honest truth is that I have more homework to do; we tend to take the pragmatic approach that a theoretical problem is uninteresting until we have real apps with real unsolvable problems. So I need to go find some more problem cases and understand them. In the interest of making this thread complete, I wanted to add a concern or two I forgot, and to belabor a point or two (that's your clue to tune out now, folks ). Specifically, there are other areas of interest when you think about timing and scheduling. First is the Windows very clear cut 'foreground window' boost. I have no idea how this maps into the Linux interactivity strategy. They seem to be roughly equivalent, and I never found an application that relied on that timing. Second, the exact sequence of when a thread yields or not on Windows is not something I'm sure I fully learned; I did my best, but my gut tells me that I must have missed some cases. The main trick as we make sys calls here is to make sure that we don't accidentally yield at times when Windows wouldn't. That connects to the theoretical flaw in Wine (the whole use of the Wine server) that should make us vulnerable to all sorts of unexpected context switches, creating timing patterns unfamiliar to Windows applications, and causing problems. And yet, from observation, I never see any such unexpected context switches. The Linux kernel priority boost for pipes seems to protect us here; we should make sure we understand why and let the kernel guys know that we depend on it, so they don't knock it out from under us some day. Fourth, based on your reply to my earlier email, I suspect I do not understand how time quanta are assigned. In fact, I had come to some conclusions at one point last fall, that I can no longer convince myself of (I was persuaded that a thread that constantly yielded had it's time quanta dranstically reduced; I can no longer reproduce that). Further, time quanta differences can be crippling to Wine. Photoshop, for example, relies on reliable 5ms timing, and if it doesn't get it, it doesn't work. Similarly, I could swear I had a problem case in IE where two threads were interdependent, and the one thread never got a large enough quanta to keep the second thread happy (and this then caused a spiral that led to the small quanta for thread A). Sadly, I didn't take good notes, so I have to go back and relearn that case again. And, knowing me, I probably completely misunderstood it anyways :-/. Sorry to ramble on; it's just tough around here, because everyone is tired of hearing me claim that every bug is a timing problem... Cheers, Jeremy
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.
Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]
[snipping further proof that I don't understand a wide range of issues ] Fourth, based on your reply to my earlier email, I suspect I do not understand how time quanta are assigned. In fact, I had come to some conclusions at one point last fall, that I can no longer convince myself of (I was persuaded that a thread that constantly yielded had it's time quanta dranstically reduced; I can no longer reproduce that). Further, time quanta differences can be crippling to Wine. Photoshop, for example, relies on reliable 5ms timing, and if it doesn't get it, it doesn't work. Similarly, I could swear I had a problem That can't be true. What you are saying is it needs at least 5ms timeslice on hardware that is equal to or faster than the machine you tested it on. We cannot guarantee any timeslice of any size will occur uninterrupted in the linux kernel. For tasks that are not nice'd, the usual minimum slice is 10ms. But if something higher priority than it wakes up in the interim, it will be preempted even if it is 50 microseconds into its timeslice. No, it is true. Your typical Photoshop user relies on the fact that Photoshop is the only application of any priority on the machine; Photoshop has a thread that runs that samples the mouse position every 5 ms; if it doesn't get it's samples in the right amount of time, you don't draw smooth curves. (It may be a timer event callback routine, or a thread that is woken up by a timer event, I can't recall exactly atm). I suspect that if you start a heavy compile on a Windows box, Photoshop won't paint right, just as it wouldn't if you burdened the CPU on Linux. What we need to protect is the apples to apples case - when Photoshop is the only app using the CPU with Wine, it needs to draw smoothly, and for that, it needs to know that the thread it has marked as super duper high priority will get run every 5 ms as it has requested. (My gut reaction to this was that it was horrid programming on Adobe's part; but they are trying to provide extremely fine resolution on drawing, and their approach makes sense in that context. I am now persuaded of their competence ). Cheers, Jeremy
Wine and FreeBSD
Hello all, First, happy to see the new release of WINE 20050111 for FreeBSD (and previous 20041201) I obtained and compiled the latest version for my standard FreeBSD 5.3 install. Upon running any windows/wine app I get the error messages err:heap:HEAP_CreateSystemHeap system heap base address 0x8000 not available err:heap:HEAP_CreateSystemHeap system heap base address 0x8000 not available err:heap:HEAP_GetPtr Invalid heap 0x0! err:heap:HEAP_GetPtr Invalid heap 0x0! err:heap:HEAP_GetPtr Invalid heap 0x0! err:heap:HEAP_GetPtr Invalid heap 0x0! Some apps (if they do not use the heap) continue to run, the apps I want to use (MS Office 2000 - Word/Excel/PowerPoint) fail as follows: MS Word will display the splash screen and then a message box with "There is not enough memory or disk space to run Word." before crashing MS Excel will start with the message box "Cannot use object linking and embedding" before starting, but attempting use excel will result in an out of memory error and then a crash MS PowerPoint doesn't even start. This is dissapointing, we have managed (http://caia.swin.edu.au/reports/041129A) to install MS Office 2K on WINE 20040505 under FreeBSD but were hoping that this newer version would fix our two discovered problems (the new file.. dialog and the pulldown menus if more than one office app is running). Unfortunately, it seems that the new version breaks everything. Further pottering around found... HEAP_CreateSystemHeap() calls MapViewOfFileEx() which calls NtMapViewOfSection() which calls map_view() which attempts a normal allocation - wine_mmap_is_in_reserved_area() == 0 calling wine_anon_mmap() The returned pointer is valid so wine_anon_mmap() succeeds BUT the returned ptr != base and so the function returns STATUS_CONFLICTING_ADDRESSES which returns up the chain and the heap allocation fails. On my system base being requested is 0x8000 and ptr being returned is 0x9996d000. This result then fails the is_beyond_limit() test... Any clues would help!! Thanks. Jason
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 es like these: ... This should take care of this little annoyance, and would make the site feel better. -- Dimi.
