Wineconf pictures
Hi folks, Here are my Wineconf pictures: http://www.flickr.com/photos/marcusmeissner/sets/72157625430516298/ (I need to add Jeremy to the group picture as someone noticed. Or photoshop a better one, or at least Martin and Andrew better ;) I also took video of Alexandres keynote as a test, but the audio quality is quite low. Also uploading a 5 minute part takes 2 - 3 hours, so its not yet fully done. http://www.youtube.com/user/msmeissn (reminder to next time dont take it in HD ... as my hands were shaky anyway and I could have taken 20 minutes in 1 piece) Ciao, Marcus
Re: wininet: add a stub for InternetShowSecurityInfoByURL
On 11/25/2010 03:29 AM, Austin English wrote: Fixes http://bugs.winehq.org/show_bug.cgi?id=25278 Shouldn't you create the A-version and forward to that one in the .spec? -- Cheers, Paul.
Re: [PATCH] ntdll: Increase size of buffer used to read lines of /proc/cpuinfo
On 11/24/10 6:56 PM, Vitaliy Margolen wrote: On 11/24/2010 12:23 PM, jimpor...@gmail.com wrote: From: James Eder -while (fgets(line,200,f) != NULL) +while (fgets(line,450,f) != NULL) You might as well then change this to "sizeof(line)". Just for my edification, is there not a better way then setting the variable line to a flexible length for this purpose. This might prevent 'growing' the variable over time. James McKenzie
Re: [PATCH] ntdll: Increase size of buffer used to read lines of /proc/cpuinfo
On 11/24/2010 12:23 PM, jimpor...@gmail.com wrote: From: James Eder - while (fgets(line,200,f) != NULL) + while (fgets(line,450,f) != NULL) You might as well then change this to "sizeof(line)". Vitaliy.
Re: Patch for bug 25063 - _pclose should wait for the command processor to terminate and return it's exit status
On 11/24/10 2:23 PM, Borut Razem wrote: Attached is the forth attempt for the patch. It is traditional to append or suffix with [Try #] so that those who are manually tracking patches can do so and so AJ can skip over your previous attempts if you made several tries between times that he looks at patches. James McKenzie
Re: Added unit test suite for process functions
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7260 Your paranoid android. === W98SE (32 bit process) === process.c:59: Test failed: unexpected number of characters: read 0, expected 7 process.c:64: Test failed: unexpected string read: read "", expected "stdout\x0a" process.c:86: Test failed: unexpected number of characters: read 0, expected 8 process.c:91: Test failed: unexpected string read: read "", expected "stdout\x0d\x0a" process.c:108: Test failed: _pclose should return after 2 seconds, but it returned after 0 seconds process.c:119: Test failed: _pclose should return 123, but it returned 0 === WNT4WSSP6 (32 bit process) === process.c:108: Test failed: _pclose should return after 2 seconds, but it returned after 0 seconds process.c:119: Test failed: _pclose should return 123, but it returned 0 === W2KPROSP4 (32 bit process) === process.c:108: Test failed: _pclose should return after 2 seconds, but it returned after 0 seconds === WXPPROSP3 (32 bit process) === process.c:108: Test failed: _pclose should return after 2 seconds, but it returned after 0 seconds === W2K3R2SESP2 (32 bit process) === process.c:108: Test failed: _pclose should return after 2 seconds, but it returned after 0 seconds === W7PROX64 (32 bit process) === process.c:108: Test failed: _pclose should return after 2 seconds, but it returned after 0 seconds === W7PROX64 (64 bit process) === process.c:108: Test failed: _pclose should return after 2 seconds, but it returned after 0 seconds
Re: msxml3/tests: move domdoc.c schema-related tests to schema.c
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7259 Your paranoid android. === WVISTAADM (32 bit schema) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation
Re: [1/2] opengl32/tests: Add tests for special case of SetPixelFormat
On Wed, Nov 24, 2010 at 11:37 PM, Henri Verbeet wrote: > On 24 November 2010 23:34, Matijn Woudt wrote: >> That's what I had in mind first too, but I couldn't figure out how to >> get that handle over to device_init (in d3d9) where the window is used >> too. >> > Why do you need it there? > The current code is using the window, I guess it wouldn't work if focus_window is still pointing to the main device context. I might be missing something here, but I don't see how this can possibly work.
Re: [1/2] opengl32/tests: Add tests for special case of SetPixelFormat
On 24 November 2010 23:34, Matijn Woudt wrote: > That's what I had in mind first too, but I couldn't figure out how to > get that handle over to device_init (in d3d9) where the window is used > too. > Why do you need it there?
Re: [1/2] opengl32/tests: Add tests for special case of SetPixelFormat
On Wed, Nov 24, 2010 at 11:30 PM, Henri Verbeet wrote: > On 23 November 2010 23:57, Matijn Woudt wrote: >> I have created a patch that uses a dummy window. Please let me know if >> this is what you had in mind. It works for the game I created the >> original patch for. >> > The basic idea is similar, but it would have to be done in wined3d, > and integrated with the rest of the context management. Look at e.g. > context_update_window(), context_validate(), context_create() and > WineD3D_CreateFakeGLContext(). > That's what I had in mind first too, but I couldn't figure out how to get that handle over to device_init (in d3d9) where the window is used too.
Re: [1/2] opengl32/tests: Add tests for special case of SetPixelFormat
On 23 November 2010 23:57, Matijn Woudt wrote: > I have created a patch that uses a dummy window. Please let me know if > this is what you had in mind. It works for the game I created the > original patch for. > The basic idea is similar, but it would have to be done in wined3d, and integrated with the rest of the context management. Look at e.g. context_update_window(), context_validate(), context_create() and WineD3D_CreateFakeGLContext().
Re: [1/2] msvcrt: Fixes multi-byte detection problem with MSVCRT_isleadbyte() (try 2)
_mbspbrk works fine. From what I could tell from my testing, MSVCRT_isleadbyte goes through _isctype and ignores the locale by using MSVCRT__ctype which never gets updated for locales (or if it does usually get updated, it's somehow completely failing). 837Dh for example is a マ in Japanese (Shift-JIS) but MSVCRT_isleadbyte before patch will not detect it but _ismbblead does. The only fix I can think of besides changing MSVCRT_isleadbyte directly is to change the calls to MSVCRT_isleadbyte with _ismbblead in the _mbspbrk function. That would be ignoring the real problem, though. On Wed, Nov 24, 2010 at 10:33 AM, Piotr Caban wrote: > _mbspbrk function needs to be fixed, not isleadbyte. > > Cheers, > Piotr >
ntdll/tests: add tests for NtQueryVolumeInformationFile with FileFsVolumeInformation class
>You should take that info from the volume (as it's done now in >GetVolumeInformation) instead of hard-coded invalid values. I guess you're right, I wasn't aware of the fact that GetVolumeInformation already does such a job. > I'm guessing some of that kernel32 functionality will need to >be moved to ntdll. yes, i had a quick look at GetVolumeInformation , seems to me it'll be quite a massive change. maybe someone more familiar with GetVolumeInformation code is more suitable to do this job
Volunteer needed - a Lurker would be perfect!
Hi Folks, Throughout the years, Wine has been lucky to have a procession of great volunteers who work on areas outside the code. And right now, we find ourselves in need of a new Wine Weekly News editor. Zachary Goldberg, our current editor, has really not been able to find the time to keep up and would appreciate it if someone else was willing to volunteer. What we need is someone who is willing to read wine-devel, and perhaps scan wine-users, and put together a periodic high level description of activity within Wine. It probably wouldn't have to be weekly; monthly would be just fine. The only requirements are enough technical background that you can make some sense of the mailing list information, some modest skills with the written word, and the willingness to help. In exchange, you'll earn fame, fortune (well, okay, maybe a free beverage once a year), and the deep satisfaction of being a critical voice for the Wine project. If you're interested, email me privately. Cheers, Jeremy
Re: [1/2] msvcrt: Fixes multi-byte detection problem with MSVCRT_isleadbyte() (try 2)
_mbspbrk function needs to be fixed, not isleadbyte. Cheers, Piotr
Re: Wineconf notes?
On Wed, Nov 24, 2010 at 04:18:43PM +0200, Damjan Jovanovic wrote: > Hi > > Can those of us that didn't go to Wineconf this year please see some > videos/slides/notes from those that did? I added a section to the wiki for it, please upload and link the slides there. :) http://wiki.winehq.org/WineConf2010 Ciao, Marcus
Wineconf notes?
Hi Can those of us that didn't go to Wineconf this year please see some videos/slides/notes from those that did? Thank you Damjan Jovanovic
Re: msvcrt: Add missing dereference of the time pointer.
Yes, you're right. Thank you for spotting.
Eryk
2010/11/24 Michael Stefaniuc :
> ---
> Eryk,
>
> I guess this is what you had in mind as checking the pointer for greater
> 0 is redundant as it is already not-NULL.
>
>
>
>
> dlls/msvcrt/time.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/dlls/msvcrt/time.c b/dlls/msvcrt/time.c
> index 7ccdc7d..4150156 100644
> --- a/dlls/msvcrt/time.c
> +++ b/dlls/msvcrt/time.c
> @@ -913,7 +913,7 @@ int CDECL MSVCRT__ctime64_s(char *res, MSVCRT_size_t len,
> const MSVCRT___time64_
> return MSVCRT_EINVAL;
> }
> res[0] = '\0';
> - if( !MSVCRT_CHECK_PMT( time != NULL ) || !MSVCRT_CHECK_PMT( time > 0 ) )
> + if( !MSVCRT_CHECK_PMT( time != NULL ) || !MSVCRT_CHECK_PMT( *time > 0 ) )
> {
> *MSVCRT__errno() = MSVCRT_EINVAL;
> return MSVCRT_EINVAL;
> @@ -946,7 +946,7 @@ int CDECL MSVCRT__ctime32_s(char *res, MSVCRT_size_t len,
> const MSVCRT___time32_
> return MSVCRT_EINVAL;
> }
> res[0] = '\0';
> - if( !MSVCRT_CHECK_PMT( time != NULL ) || !MSVCRT_CHECK_PMT( time > 0 ) )
> + if( !MSVCRT_CHECK_PMT( time != NULL ) || !MSVCRT_CHECK_PMT( *time > 0 ) )
> {
> *MSVCRT__errno() = MSVCRT_EINVAL;
> return MSVCRT_EINVAL;
> --
> 1.7.3.2
>
Re: COM implementation clean up
Hello,
Alexander Kochetkov wrote:
> The code like
> static inline MyObject *impl_from_IMyInterface(IMyInterface *iface)
> {
> return (MyObject*)((char*)iface - FIELD_OFFSET(MyObject,
> IMyInterface_iface));
> }
>
> could be replaced with
> static inline MyObject *impl_from_IMyInterface(IMyInterface *iface)
> {
> return container_of(MyObject, IMyInterface_iface);
> }
container_of is Linux Kernel specific. But Windows has such a macro too
called CONTAINING_RECORD().
bye
michael
Re: COM implementation clean up
Hi all,
The code like
static inline MyObject *impl_from_IMyInterface(IMyInterface *iface)
{
return (MyObject*)((char*)iface - FIELD_OFFSET(MyObject,
IMyInterface_iface));
}
could be replaced with
static inline MyObject *impl_from_IMyInterface(IMyInterface *iface)
{
return container_of(MyObject, IMyInterface_iface);
}
Cheers,
Alexander.
