Re: uxtheme.dll
On Wed, 2003-10-01 at 12:21, Kevin Koltzau wrote: I'm aware of the scope of the project. The general design of uxtheme lends itself well to being done incrementally, eg. controls could be modified as support for the particular control is implemented, etc. Also part of the API are a few functions (IsThemeActive IsAppThemed) which will allow themes to be disabled in the beginning for theme aware applications until sufficient support has been built or if themes are disabled via config/registry. Some time ago I started hacking in support for GTK themes. When I first suggested this project to the list there was suggestions that doing it with uxtheme.dll was the way to go. I agreed, but didn't have winxp to play with, so I kept tinkering on this project with the intent of learning a bit more about how wine works (which meant learning a lot about how GDI and X works, though I didn't realise that I'd need to know that stuff when I started on the project). I actually managed to get some results which were starting to look promising (though there's no way I'd submit that code as a patch). Screenshots here (the checkbox being the only important part): http://james.id.au/wine/wine-ss1.png http://james.id.au/wine/wine-ss2.png http://james.id.au/wine/wine-ss3.png Anyway, the reason I'm posting is not to suggest that this code be used (nor the approach I took), but to mention that if theming code is to be written that I think it's really important to have a way to pass off rendering of controls etc to a .so that can be dlopened and called with dlsym. IIRC the existing system uses a function lookup table, so there shouldn't be much that needs to change for this to occur -- only the initialisation of this function table and probably some hooks so that these .sos can detect whether or not they'll work with the current configuration (as an example the way I was doing gtk theming won't work with anything that isn't x11drv. I don't like breaking encapsulation like this, but it sounds like it's practical in this case). I don't know if I can be of any help, but I'm interested in trying -- please keep me posted. James. On Tuesday 30 September 2003 02:21 am, Roderick Colenbrander wrote: I hope you know what you will begin with. (For the ones that don't know uxtheme.dll is the dll that takes care of all theming on WinXP and it is the dll that dlls like comctl32 and all others use for theming) Some time ago I checked out uxtheme.dll a bit and it seems that it needs changes all over Wine. As I understand it WinXP ships with two sets of comctl32.dll and friends. One is the old version and one is a new uxtheme aware version. The uxtheme aware version contains lots of changes and uses uxtheme for theming. To use uxtheme you need to add uxtheme support to the dlls that need it which looks like a huge job. Perhaps this is something post Wine-1.0? Roderick Colenbrander
Regression in lstrcmpiA (occurred in late June, NLS related)
When lstrcmpiA was moved from ole2nls.c to locale.c, (around 28th June) the
results of comparisons in some cases became reversed. For example, the
underscore now returns as greater than alphabetic characters, whereas it used
to return as less than alphabetic characters. The older behaviour was
consistent with Win2k.
The output below is from the following source:
---begin test program---
#include windows.h
#include stdio.h
char *test_strings[] =
{
_,
A,
a,
z,
Z,
0
};
void
test_string(char *pch)
{
char **ppch = test_strings;
while (*ppch)
{
printf(%s\t%s\t%d\n, pch, *ppch, lstrcmpiA(pch, *ppch));
++ppch;
}
}
int
main(int argc, char **argv)
{
char **ppch = test_strings;
while (*ppch)
test_string(*ppch++);
return 0;
}
---end test program---
---Wine output from immediately before the change---
_ _ 0sorts
_ A -1
_ a -1
_ z -1
_ Z -1
A _ 1
A A 0
A a 0
A z -1
A Z -1
a _ 1
a A 0
a a 0
a z -1
a Z -1
z _ 1
z A 1
z a 1
z z 0
z Z 0
Z _ 1
Z A 1
Z a 1
Z z 0
Z Z 0
---End---
---Wine output from immediately after the change---
_ _ 0
_ A 1
_ a 1
_ z 1
_ Z 1
A _ -1
A A 0
A a 0
A z -1
A Z -1
a _ -1
a A 0
a a 0
a z -1
a Z -1
z _ -1
z A 1
z a 1
z z 0
z Z 0
Z _ -1
Z A 1
Z a 1
Z z 0
Z Z 0
~---End---
Re: Does anyone know about WM_SETFOCUS and EN_SETFOCUS
Is anyone out there an expert in Windows focus handling? I have problems with our application and the focus handling in places. Basically it seems to me that there is some sort of logic in windows whereby the code calls PostMessage (WM_SETFOCUS) but the result is that the parent of the target window receives WM_COMMAND EN_SETFOCUS instead. Does anyone know anything about such translations? From MSDN: The EN_SETFOCUS notification message is sent when an edit control receives the keyboard focus. The parent window of the edit control receives this notification message through a WM_COMMAND message. LRESULT CALLBACK WindowProc( HWND hwnd, // handle to window UINT uMsg, // WM_COMMAND WPARAM wParam, // edit control identifier, EN_SETFOCUS LPARAM lParam// handle to edit control (HWND) ); Parameters wParam The low-order word specifies the edit control identifier. The high-order word specifies the notification message. lParam Handle to the edit control. Remarks The parent window will always get a WM_COMMAND message for this event, it does not require a notification mask sent with WM_SETEVENTMASK. Rich Edit: For information about the compatibility of rich edit versions with the various system versions, see About Rich Edit Controls.
Re: Regression in lstrcmpiA (occurred in late June, NLS related)
Further investigation reveals another problem in lstrcmpiA: MSDN documents
this function as executing what it describes as a word sort, which results
in the words co-op and coop sorting to the same place. This is almost a
correct description of what happens (if the strings come out to be the same
after the word sort it appears that it does a regular comparison as well).
The attached files demonstrate the divergence of wine in this regard as well
as the original regression.
#include windows.h
#include stdio.h
char *test_strings1[] =
{
_,
A,
a,
z,
Z,
0
};
char *test_strings2[] =
{
coop,
co-op,
co-op a,
coop a,
co-op b,
coop b,
0
};
void
test_string(char *pch, char **test_strings)
{
char **ppch = test_strings;
while (*ppch)
{
printf(%s\t%s\t%d\n, pch, *ppch, lstrcmpiA(pch, *ppch));
++ppch;
}
}
void
do_test(char **test_strings)
{
char **ppch = test_strings;
while (*ppch)
test_string(*ppch++, test_strings);
}
int
main(int argc, char **argv)
{
do_test(test_strings1);
do_test(test_strings2);
return 0;
}
_ _ 0
_ A -1
_ a -1
_ z -1
_ Z -1
A _ 1
A A 0
A a 0
A z -1
A Z -1
a _ 1
a A 0
a a 0
a z -1
a Z -1
z _ 1
z A 1
z a 1
z z 0
z Z 0
Z _ 1
Z A 1
Z a 1
Z z 0
Z Z 0
coopcoop0
coopco-op -1
coopco-op a -1
coopcoop a -1
coopco-op b -1
coopcoop b -1
co-op coop1
co-op co-op 0
co-op co-op a -1
co-op coop a -1
co-op co-op b -1
co-op coop b -1
co-op a coop1
co-op a co-op 1
co-op a co-op a 0
co-op a coop a 1
co-op a co-op b -1
co-op a coop b -1
coop a coop1
coop a co-op 1
coop a co-op a -1
coop a coop a 0
coop a co-op b -1
coop a coop b -1
co-op b coop1
co-op b co-op 1
co-op b co-op a 1
co-op b coop a 1
co-op b co-op b 0
co-op b coop b 1
coop b coop1
coop b co-op 1
coop b co-op a 1
coop b coop a 1
coop b co-op b -1
coop b coop b 0
_ _ 0
_ A 1
_ a 1
_ z 1
_ Z 1
A _ -1
A A 0
A a 0
A z -1
A Z -1
a _ -1
a A 0
a a 0
a z -1
a Z -1
z _ -1
z A 1
z a 1
z z 0
z Z 0
Z _ -1
Z A 1
Z a 1
Z z 0
Z Z 0
coopcoop0
coopco-op 1
coopco-op a 1
coopcoop a -1
coopco-op b 1
coopcoop b -1
co-op coop-1
co-op co-op 0
co-op co-op a -1
co-op coop a -1
co-op co-op b -1
co-op coop b -1
co-op a coop-1
co-op a co-op 1
co-op a co-op a 0
co-op a coop a -1
co-op a co-op b -1
co-op a coop b -1
coop a coop1
coop a co-op 1
coop a co-op a 1
coop a coop a 0
coop a co-op b 1
coop a coop b -1
co-op b coop-1
co-op b co-op 1
co-op b co-op a 1
co-op b coop a -1
co-op b co-op b 0
co-op b coop b -1
coop b coop1
coop b co-op 1
coop b co-op a 1
coop b coop a 1
coop b co-op b 1
coop b coop b 0
Re: Start menu (continued ...)
Just a thought which may or may not be completely out of proportion: In which sense can Wine and native Desktop be easily synchronized? I see a number of problems such as who should synchronize to whom. Why make an arbitrary Unix desktop synchronize to a Wine start menu? Why not the other way around? Wine builds in all other areas on top of the existing Unix platform. Is it really useful to start to base the native Unix desktop on Wine? Or is this the first step in getting Wine as yet another Unix desktop into the picture? I am not talking about a complete desktop, just about a little submenu in your K-menu, or Gnome menu, or whatever menu one could be using. Such a thing already exists, but is implemented with scripts instead of with a Wine deamon/linux client. The current system does not seem to be to flexible. Therefore, I suppose that a setup with wine deamon as a server and a linux client would be better. For example: one could easily add support for more desktop environments, without the changing the deamon. Robert
Re: uxtheme.dll
This is very kickass dude. I think this is the right method of supporting themes for WINE. KDE can already do GTK themes with a little bit of tweaking so it will support both Linux Desktops and GTK themes are now supported under Windows with GTK-Win32 so maybe we can even use this in ReactOS when its ready. Thanks Steven --- James Gregory [EMAIL PROTECTED] wrote: Some time ago I started hacking in support for GTK themes. When I first suggested this project to the list there was suggestions that doing it with uxtheme.dll was the way to go. I agreed, but didn't have winxp to play with, so I kept tinkering on this project with the intent of learning a bit more about how wine works (which meant learning a lot about how GDI and X works, though I didn't realise that I'd need to know that stuff when I started on the project). I actually managed to get some results which were starting to look promising (though there's no way I'd submit that code as a patch). Screenshots here (the checkbox being the only important part): http://james.id.au/wine/wine-ss1.png http://james.id.au/wine/wine-ss2.png http://james.id.au/wine/wine-ss3.png Anyway, the reason I'm posting is not to suggest that this code be used (nor the approach I took), but to mention that if theming code is to be written that I think it's really important to have a way to pass off rendering of controls etc to a .so that can be dlopened and called with dlsym. IIRC the existing system uses a function lookup table, so there shouldn't be much that needs to change for this to occur -- only the initialisation of this function table and probably some hooks so that these .sos can detect whether or not they'll work with the current configuration (as an example the way I was doing gtk theming won't work with anything that isn't x11drv. I don't like breaking encapsulation like this, but it sounds like it's practical in this case). I don't know if I can be of any help, but I'm interested in trying -- please keep me posted. James. __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Translating WINE using dedicated tools
[Please CC me, I'm not subscribed to this list] Hello, I've read in the last Wine KC that you are getting troubles to keep the translation of wine uptodate. I am pretty well involved in the translation of free software, and this is a common issue for all of us. It is so common that I did a program to deal easily with the translation of any kind of resource. This is called po4a (po for anything), and you can find more details about this on http://savannah.nongnu.org/projects/po4a and http://www.nongnu.org/po4a/ . The idea is to ease the convertions resource - po file and then po - resource when the translation is done. So, checking if the translation is uptodate is as easy as used the dedicated tools of the gettext world. Po4a is fully modular, and all we have to do to let wine using it is a new (perl) module to parse it. You can find more details about how to do a module using `perldoc Locale::Po4a::TransTractor` once the program is installed. I would like to help here, but I need to know the gramar of the resource files. Do you have any parsers around there ? The better would be to have Perl based ones, since this is the language used in po4a. What do you guys think? Mt. [Please CC me, I'm not subscribed to this list] -- The most exciting phrase to hear in science, the one that heralds new discoveries, is not Eureka! (I found it!) but That's funny ... --- Isaac Asimov pgp0.pgp Description: PGP signature
ssl and kerberos
I need some help with configure.ac. In RH8 and 9, openssl is compiled with krb5 support. The problem comes from the fact that the kerberos files are not under /usr/include, rather /usr/kerberos/include. So when ssl.h includes krb5.h, it can't find it. It'd need to be detected and add /usr/kerberos/include to the list of EXTRAINCL if compiling with only ssl.h is not enough. (I never noticed before because I had recompiled openssl locally to not use kerberos at all, and on the other machine I never looked that closely as everything is installed stock) Once that is fixed, it will trigger another bug in the kerberos part of openssl, namely that FAR is used, but we'll get to that bridge another time. Vincent
linuxtag in Dresden, Germany
Hi folks, is there anybody at the linuxtag in Dresden, Germany on Sat. October 18th 2003? I'd like to see you around. Bernhard
Re: Does anyone know about WM_SETFOCUS and EN_SETFOCUS
Bill Medland [EMAIL PROTECTED] writes: Are you saying that you believe that the edit control itself sends the EN_SETFOCUS? Yes, the edit control sends it when it gets a WM_SETFOCUS. That's how all the notification messages work. Our software includes some tracing and what I see in it suggests that under Windows there are EN_SETFOCUS messages whereas under Wine they are WM_SETFOCUS, and I am trying to understand why. Probably the focus is set to the parent window directly instead of being set to the edit control. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Updated winetests.exe
Dimitrie O. Paun [EMAIL PROTECTED] writes:
On Tue, 30 Sep 2003, Ferenc Wagner wrote:
I thought the build tag (which can be any one-line string)
was enough. Why do we need anything else?
That works nicely IF Jakob builds the tests only on official
releases
Why? The current simple scheme of setting it to the date
should work if we do not build twice in 24 hours. If that
is not enough, we can include a full CVS time specification
down to seconds, as I said, it is a simple tag, not parsed,
not used for anything except matching.
(which should happen anyway).
Why, again?
In fact, the build script can be smart enough to notice if
we're not using an offcial release, and provide a
different build tag.
Yes, it should include the full CVS date then, not a big
deal. Yeah, when summarizing an offical release, I can
provide LXR links as an extra.
-- a simple to generate format would be: [...]
It can't be that hard: we mainly have to
for dll in $DLLS
echo *** $dll
ver=`cvs status $file | grep Working | awk '{print $3}'`
for file in dlls/$dll/tests
echo * $file $ver
echo MinGW:
compile_file_with_MinGW
echo MSVC:
compile_file_with_MSVC
done
wine dlls/$dll/tests/$dll_test.exe.so
done
Well, the trick is in the compile_file_with_* routines. The
MinGW way is specified in the Makefiles, how would you
incorporate them? The MSVC way is in the .dsp-s, which is
even worse. Then you can not invoke $dll_test.exe.so,
because MinGW results in $dll_crosstest.exe while MSVC in
something else again. One more thing, although the present
build system ensures (AFAICT) that every .c file corresponds
to a test, it may not forever be the case. And errors are
more frequent in the linking phase anyway.
So, what I find reasonable is capturing the whole make
output in a file for every unit, and publishing it on the
condition that the make fails. It would be easy for MinGW
and possibly impossible for MSVC, I do not have a clue about
that. Sad to say this. Also this is the reason I mentioned
tar. Not for the reports, but for the master files, which
could avoid the mailing list anyway. To be honest, I fail
to see the point of the mailing list. These reports are
rather unsuitable for human consumption (strictly IMO).
we really need to automate the build procedure, I don't
think manual stuff will cut it.
Can do with MinGW, for sure. But for MSVC??
In fact, the build procedure should be included in our
makefiles, and we can invoke it automatically on a new
Wine release through the make_release script...
Fine vision, I am sold on it, although I would like to
provide a way to make more frequent builds.
Feri.
Re: I/O port access broken (SEH broken)
Andreas == Andreas Mohr [EMAIL PROTECTED] writes: Andreas Hi all, sounds like the recent architectural changes were a bit Andreas too much: now I get Andreas Unhandled exception: privileged instruction in 32-bit code Andreas (0x0040348b). In 32-bit mode. 0x0040348b Andreas (FT255_T32.exe..text+0x248b in FT255_T32.exe): outb %al,%dx Wine-dbg Andreas with a parallel port flash tool I'm trying to use, whereas Andreas before it used to work with both direct I/O port access and Andreas ppdev. Andreas In other words: exception handling about I/O port access has Andreas been broken. Another related problem: I need inport/outport in some private VXD reimplementation too. The reimplementation resided in my win32/device.c file. Do I need to do LoadLibrary(winedos) GetProc(xxx,Inport) in my code now? Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Translating WINE using dedicated tools
Once wine has final docs this would be great, the wine docs will change before 1.0 (The wine-user docs are config-file orientated, and many other things may change before 1.0), the wine-devel docs don't really need translating as most developers know English, and the wine programs and dlls can be translated manually without any difficulty, but once we have a final version of wine user docs and winehq web site this tool could be very useful.
Re: Updated winetests.exe
On October 1, 2003 06:25 am, Ferenc Wagner wrote:
Dimitrie O. Paun [EMAIL PROTECTED] writes:
Why? The current simple scheme of setting it to the date
should work if we do not build twice in 24 hours. If that
is not enough, we can include a full CVS time specification
down to seconds, as I said, it is a simple tag, not parsed,
not used for anything except matching.
Well, normally we should build on official releases, as it
avoids confusion: we have well known files, etc. to refer to.
I agree with you that we should have a way to do intermediate
releases, but if we do them we should mark them somehow (that
should be easy to do). For official releases we can't just use
the current date, simply because Alexandre may do the release
at night (say 23:00, as he usually does), and we will not get
around to it until the next day. Granted, non of these are
real problems, I'm just saying we need to be careful how we
label things so we can make sense of them when we look back.
Yes, it should include the full CVS date then, not a big
deal. Yeah, when summarizing an offical release, I can
provide LXR links as an extra.
Even for non-official builds we should have the CVS version
of the file (IF the file was not modified in the build tree),
so we can provide cvsweb links there as well.
Well, the trick is in the compile_file_with_* routines. The
True. Let's reorganize things a bit:
make -s #build the entire tree under Linux
for dll in $DLLS; do
wine dlls/$dll/tests/$dll_test.exe.so
for file in dlls/$dll/tests/*.c; do
ver=`cvs status $file | grep Working | awk '{print $3}'`
echo * $file $ver
done
done
for build in $BUILD_SYSTEMS; do
echo *** Build: $build
make -s $build 2$build.errors #don't take this to literal :)
cat $build.errors
done
This should be doable, and parsable, right?
we really need to automate the build procedure, I don't
think manual stuff will cut it.
Can do with MinGW, for sure. But for MSVC??
We don't need to _ship_ different binaries. All we need to make
sure is that tests build. If we can't do that for MSVC, then
too bad, so sad -- we can't get stuck there. But there is a simple
way to do the MSVC build: AFAIK cl.exe works under Wine, so we
can have targets in the Makefiles that build with that. So what
we need is an installed MSVC, an version of Wine that is _known_
to run cl.exe just fine, and a bit of elbow grease.
But I think we are going in the wrong direction here. This is more
part of a different project, a porting status (Steven is working on
that). Maybe we should drop all this and just focus on tests results,
it doesn't make sense to track build status just for some files here,
when we're (hopefully) going to do the tracking for the entire tree.
Fine vision, I am sold on it, although I would like to
provide a way to make more frequent builds.
For sure, that should be fairly simple, all we have to make
sure is we do a decent job with the labels.
--
Dimi.
Re: Translating WINE using dedicated tools
and winehq web site This is if Jeremy Newman wants to have the site translated. As I didn't want to translate anything before being sure it would be accepted I've emaild him various times to know if/how winehq should be translated, and I never got an answer.
Re: I/O port access broken (SEH broken)
Andreas Mohr [EMAIL PROTECTED] writes: Unhandled exception: privileged instruction in 32-bit code (0x0040348b). In 32-bit mode. 0x0040348b (FT255_T32.exe..text+0x248b in FT255_T32.exe): outb %al,%dx Wine-dbg with a parallel port flash tool I'm trying to use, whereas before it used to work with both direct I/O port access and ppdev. In other words: exception handling about I/O port access has been broken. That's the way it's supposed to work under NT. You probably need to run that app with Windows version set to NT. -- Alexandre Julliard [EMAIL PROTECTED]
Re: winealsa: improve sound quality for IDsDriverImpl
Dimitrie O. Paun wrote: The best thing to do is to post it here so we can see what we are talking about... And yes, we all want only the best code for wine :) The code is already submitted in my patch. After thinking twice, I found that the runtime check can be sped up. Calling snd_async_callback_t twice is enough. Because we could commit the whole buffer for the first time, ALSA driver will know the buffer is full. If the buffer will be reallocated, it is the right time for the driver to perform the action. And the new address will be returned next time we call snd_pcm_mmap_begin. We need not wait for the whole buffer to be played once. And I got some new information about the noticeable interval. Seems it's something about the sound data format was not correctly set, for sox -c1 -r44100 -sw /usr/share/sounds/pop.wav -tossdsp /dev/audio wine winamp has the problem, but sox -c1 -r44100 -sb /usr/share/sounds/pop.wav -tossdsp /dev/audio wine winamp is unbelievably good. How could it be? I should find out if it's something is wrong with my system or something else. -- Dimi.
Fix for notepad and winecfg losing focus
Hello! Our notepad has a bug that causes it to lose focus on startup. In order to initialize the new document, WinMain() calls DIALOG_FileNew(), which focuses the editor subwindow. The problem is that it happens before ShowWindow() is called on the main window. As a result, focusing the subwindow causes activation of its parent without actually showing it. This leaves the code in dlls/user/focus.c in the confused state. When ShowWindow() is called, the window is not brought to foreground because it's already active. Then set_active_window() decides to draw the inactive caption because the window is not in foreground. Windows 2000 doesn't show this problem. Notepad and winecfg are focused properly on startup. I think there are many solutions to this problem. For example, the check for visibility could be moved from SetActiveWindow() to the lower-level set_active_window(). The attached patch is minimally intrusive. This decreases its chances of breaking anything, but it may not be the best radical solution. If SetFocus() finds an invisible window while looking for the ultimate parent, it fails. The same is already done for minimized and disabled windows. The patch has been successfully tested in the non-managed and desktop modes. The managed node is not affected because the captions are not shown. Cygwin setup (http:/www.cygwin.com/setup.exe) is also positively affected. === --- dlls/user/focus.c +++ dlls/user/focus.c @@ -258,6 +258,7 @@ HWND WINAPI SetFocus( HWND hwnd ) HWND parent; LONG style = GetWindowLongW( hwndTop, GWL_STYLE ); if (style (WS_MINIMIZE | WS_DISABLED)) return 0; +if (!(style WS_VISIBLE)) return 0; parent = GetAncestor( hwndTop, GA_PARENT ); if (!parent || parent == GetDesktopWindow()) break; hwndTop = parent; === -- Regards, Pavel Roskin
Re: Updated winetests.exe
Ferenc Wagner wrote: Fine vision, I am sold on it, although I would like to provide a way to make more frequent builds. I don't have time for more detailed replies just now, but I think more frequent builds would be very good. Otherwise test maintainers would have a very long turnaround time for bug fixes. regards, Jakob
Re: Updated winetests.exe
Dimitrie O. Paun wrote: But I think we are going in the wrong direction here. This is more part of a different project, a porting status (Steven is working on that). Maybe we should drop all this and just focus on tests results, it doesn't make sense to track build status just for some files here, when we're (hopefully) going to do the tracking for the entire tree. Excellent. Lets separate these tasks - that of regr. testing and checking build status! regards, Jakob
Re: Regression in lstrcmpiA (occurred in late June, NLS related)
On Wed, 1 Oct 2003 18:25, Dmitry Timoshkov wrote: The older behaviour was consistent with Win2k. ... and only with Latin1 locale, failing with others. Yes, but it this also means it worked for ASCII-7. Right now it doesn't even work for that. This creates problems for some applications, such as those that incorrectly use lstrcmpA to do binary searches on internal ordered keyword tables where the keywords can include punctuation characters or underscores. It means they fail to find some of their keywords, the result being spurious error results. Since the ASCII-7 range is the same regardless of character set, this wrong use of lstrcmpA happens to work on Windows if all the keywords in such a table are limited to that range.
New winetests.exe
New build of winetests.exe with tests from CVS 2003-10-02 http://vmlinux.org/~jakov/Wine/
Re: Regression testing framework
On Thu, 2 Oct 2003, Jakob Eriksson wrote: The feature requests come in faster now and I also have less time to work on this stuff for the moment, so I release my little baby into the wild: Cool, thanx! It needs to be integrated with the rest of the wine build system, maybe a bit of cleanup, etc. I will take care of it. -- Dimi.
Re: Implementation of GetCompressedFileSize[AW]
FIXME about GetCompressedFileSizeA was too annoying when running Cygwin programs, so I implemented it. The code uses st_blocks when possible to account for sparse files and falls back to st_size if st_blocks is missing in struct stat. The code uses shift operations so that both systems with 32-bit and 64-bit off_t will do their best to provide accurate results. Works cool, but you could return INVALID_FILE_SIZE when the function fails. I patched it into win32/newfns.c for long time but never sent a patch. OT : Too bad that we dont have GetProcessMemoryInfo, this is what keeps cygwin programs unable to start into bash. = Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels What if tomorrow the War could be over ? Morpheus, in Reloaded. ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
