Re: [ros-dev] lwIP testing request

[Gregor Schneider]

Hi altogether,

I just tried second ISO and got to say that the download performance using
lwip is marvellous. Great work Claudiu, Art & Cameron!
One minor quirk was the corrupted Firefox 5 download, but that might have
been due to other components and not lwip itself.

Apart from downloads, basically nothing in ReactOS works which is quite
awkward.
These are some of the problems I encountered:
rapps.exe -> internet & network -> firefox 5 -> file corrupt after download
rapps.exe -> internet & network -> firefox 3.0 -> not enough disk space
minimizing rapps.exe gives ~10 riched20 assertions
rapps.exe -> internet & network -> firefox 3.6 -> nothing happens (link
broken?)
rapps.exe -> games -> LGeneral -> SDL.dll cannot be found after
installation, user mode crash

Best regards,
Gregor
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] shell32 vs. shell32_new

[Gregor Schneider]

Hi ros-dev,

I've seen shell32_new being added into trunk by r51768, but haven't heard of
anything else about it. From what I can see it changes shell32 from C to
C++, which looks like a good move.

Problematic seems to me that it is completely out of sync with trunk's
shell32 (judging from the translations alone).
It might also be annoying for merging future patches, since the C to C++
move changes the code substantially.

So are there any plans concering shell32_new? Do I have to merge all code
changes in C and C++ or is shell32(_old) going to be dumped anytime soon?

Best regards,
Gregor
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] Yarotows trunk integration

[Gregor Schneider]

Hi,

good to see the branch work back in trunk, I suspected this work would be
left to rot and finally be forgotten (like in most other experimental
branches). Altogether this looks like a huge step forward, got to test those
mode switches it once I have enough time.

One thing I noticed from the diffs is the eng/mem.c file, which exceeded my
EVIL / HACK threshold. Is this supposed to stay - especially in the context
of ARM3's to be proven awesomeness?

--- snippet ---

EngSecureMem(PVOID Address, ULONG Length)
{ return (HANDLE)-1; // HACK!!! }

EngUnsecureMem(HANDLE Mem)
{ if (Mem == (HANDLE)-1) return;  // HACK!!! }

--- snippet ---

Good work anyway, thanks to the people involved!

Regards,
Gregor
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Some proposals for roadmap

[Gregor Schneider]

Hi,

our bugzilla already has a similar feature, where certain bugs are marked
with a target milestone. We just don't stick to these marks and everybody
seems to set them according to personal perception. PLus we don't use these
to generate some kind of release graph.
Anyway: the biggest problem is, that we don't define our release dates based
on bugs only. That's possible as soon as a software product is feature
complete, which is not quite the case here.

Best regards,

Gregor

2010/6/1 Javier Agustìn Fernàndez Arroyo 

> hello,
>
> i have thinking about an easy way to show people the ReactOS roadmap, and
> there came to my mind two projects where i have submitted some bug reports
> before joining ReactOS. They use the "milestone" field in their bug reports
> for the roadmaps, and its a quite clean way to show it, IMO
>
> Here are the links
>
> Is there any way to do something similar using Bugzilla? (none of these 2
> projects use  this Bug Management System)
>
> http://www.kdenlive.org/mantis/roadmap_page.php
>
> http://developer.pidgin.im/roadmap
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [tkreuzer] 47484: - add explicit braces to avoid ambiguous 'else' - fix deprecated conversion from string constant to 'char*'

[Gregor Schneider]

Unlikely it will get lost considering this header:

/*
 * ReactOS Explorer
 *
 * Copyright 2009 Andrew Hill 

Best regards,

Gregor

2010/5/31 Ged Murphy 

> This is Wine code, it'll get lost in the next sync
>
> On 31 May 2010 05:13,  wrote:
>
>> Author: tkreuzer
>> Date: Mon May 31 06:13:40 2010
>> New Revision: 47484
>>
>> URL: http://svn.reactos.org/svn/reactos?rev=47484&view=rev
>> Log:
>> - add explicit braces to avoid ambiguous 'else'
>> - fix deprecated conversion from string constant to 'char*'
>>
>> Modified:
>>trunk/reactos/dll/win32/browseui/internettoolbar.cpp
>>
>> Modified: trunk/reactos/dll/win32/browseui/internettoolbar.cpp
>> URL:
>> http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/browseui/internettoolbar.cpp?rev=47484&r1=47483&r2=47484&view=diff
>>
>> ==
>> --- trunk/reactos/dll/win32/browseui/internettoolbar.cpp [iso-8859-1]
>> (original)
>> +++ trunk/reactos/dll/win32/browseui/internettoolbar.cpp [iso-8859-1] Mon
>> May 31 06:13:40 2010
>> @@ -414,10 +414,16 @@
>>{
>>SMINFO *infoPtr = (SMINFO *)lParam;
>>if ((infoPtr->dwMask & SMIM_FLAGS) != 0)
>> +   {
>>if (psmd->uId == FCIDM_MENU_FAVORITES)
>> +   {
>>infoPtr->dwFlags |=
>> SMIF_DROPCASCADE;
>> -   else{
>> -   infoPtr->dwFlags |=
>> SMIF_TRACKPOPUP;}
>> +   }
>> +   else
>> +   {
>> +   infoPtr->dwFlags |=
>> SMIF_TRACKPOPUP;
>> +   }
>> +   }
>>if ((infoPtr->dwMask & SMIM_ICON) != 0)
>>infoPtr->iIcon = -1;
>>}
>> @@ -1213,7 +1219,7 @@
>>CComPtr
>>  objectWithSite;
>>CComPtr
>> contextMenu;
>>CMINVOKECOMMANDINFO
>> commandInfo;
>> -   char
>>  *searchGUID = "{169A0691-8DF9-11d1-A1C4-00C04FD75D13}";
>> +   const char
>>  *searchGUID = "{169A0691-8DF9-11d1-A1C4-00C04FD75D13}";
>>HRESULT
>> hResult;
>>
>>// TODO: Query shell if this command is enabled first
>>
>>
>>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Recent Bootvid Commit

[Gregor Schneider]

Hey Ros Arm,

if you feel like extending and optimizing that code, please feel free to do
so.
>From the old code and the comments I could only guess what it was trying to
do except the standard blit. Most parts of it worked by chance, so I added a
very basic (and common sense) implementation and tested it with plain
non-RLE bitmaps by converting those in ntoskrnl\inbv\logo\ for testing.

At the moment this routine is not even used as it seems, the ntoskrnl
bitmaps are RLE coded by default. Those are processed by the RLEBitBlt
function in the same file. This functions looks a bit better, but could
still require some changes here and there.

Best regards,
Gregor


2010/5/30 Ros Arm 

> Hello!
>
> While the state of the original code is horrendous, and removing it was a
> step in the good direction, this simplified implementation omits many of the
> optimizations and specific VGA tricks that the original "author" of the code
> had intended to duplicate.
>
> If you'd like, I would be open to talking to eVb (we both have some
> experience with VGA programming) to create an efficient 4BitBlt routine
> similar to the original one that has been removed, but one that actually has
> basis in actual fact and isn't of the nature this original implementation
> was.
>
> I can see the original code was converting packed data into per-plane
> (planar) data and had special edge handling, but it looks like the original
> author did not realize this, and most of the modulo-and-shifts appear as
> bitwise ANDs (compiler optimizations), which is just plain confusing.
>
> Since the rest of bootvid is probably the same "quality", we could take a
> good look at it, both from a coding and legal standpoint, if you'd like.
>
> -r
>
> Author: gschneider
> Date: Sun May 30 01:54:47 2010
> New Revision: 47431
>
> URL: http://svn.reactos.org/svn/reactos?rev=47431&view=rev
> Log:
> [BOOTVID] Dramatically simplify 4bpp blitting routine
> See issue #5103 for more details.
>
> Modified:
>   trunk/reactos/drivers/base/bootvid/i386/vga.c
>
> Modified: trunk/reactos/drivers/base/bootvid/i386/vga.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/bootvid/i386/vga.c?rev=47431&r1=47430&r2=47431&view=diff
>
> ==
> --- trunk/reactos/drivers/base/bootvid/i386/vga.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/base/bootvid/i386/vga.c [iso-8859-1] Sun May 30
> 01:54:47 2010
> @@ -402,33 +402,20 @@
>   IN ULONG BitsPerPixel,
>   IN ULONG Delta)
> {
> -ULONG LeftAnd, LeftShifted, LeftPlusOne, LeftPos;
> -ULONG lMask, rMask;
> -UCHAR NotlMask;
> -ULONG Distance;
> -ULONG DistanceMinusLeftBpp;
> -ULONG SomeYesNoFlag, SomeYesNoFlag2;
> -PUCHAR PixelPosition, m;
> -PUCHAR i, k;
> -ULONG j;
> -ULONG x;
> -ULONG Plane;
> -UCHAR LeftArray[84];
> -PUCHAR CurrentLeft;
> -PUCHAR l;
> -ULONG LoopCount;
> -UCHAR pMask, PlaneShift;
> -BOOLEAN Odd;
> -UCHAR Value;
> +ULONG sx, dx, dy;
> +UCHAR color;
> +ULONG offset = 0;
> +const ULONG Bottom = Top + Height;
> +const ULONG Right = Left + Width;
>
>/* Check if the buffer isn't 4bpp */
>if (BitsPerPixel != 4)
>{
>/* FIXME: TODO */
>DbgPrint("Unhandled BitBlt\n"
> - "%lxx%lx @ (%lx,%lx)\n"
> - "Bits Per Pixel %lx\n"
> - "Buffer: %p. Delta: %lx\n",
> + "%lux%lu @ (%lu|%lu)\n"
> + "Bits Per Pixel %lu\n"
> + "Buffer: %p. Delta: %lu\n",
> Width,
> Height,
> Left,
> @@ -439,181 +426,28 @@
>return;
>}
>
> -/* Get the masks and other values */
> -LeftAnd = Left & 0x7;
> -lMask = lMaskTable[LeftAnd];
> -Distance = Width + Left;
> -rMask = rMaskTable[(Distance - 1) & 0x7];
> -Left >>= 3;
> -
> -/* Set some values */
> -SomeYesNoFlag = FALSE;
> -SomeYesNoFlag2 = FALSE;
> -Distance = (Distance - 1) >> 3;
> -DistanceMinusLeftBpp = Distance - Left;
> -
> -/* Check if the distance is equal to the left position and add the
> masks */
> -if (Left == Distance) lMask += rMask;
> -
> -/* Check if there's no distance offset */
> -if (DistanceMinusLeftBpp)
> -{
> -/* Set the first flag on */
> -SomeYesNoFlag = TRUE;
> -
> -/* Decrease offset and check if we still have one */
> -if (--DistanceMinusLeftBpp)
> -{
> -/* Still have a distance offset */
> -SomeYesNoFlag2 = TRUE;
> -}
> -}
> -
> -/* Calculate initial pixel position */
> -PixelPosition = (PUCHAR)VgaBase + (Top * 80) + Left;
> -
> -/* Set loop buffer variable */
> -i = Buffer;
> -
> -/* Switch to mode 0 */
> -ReadWriteMode(0);
> -
> -/* Leave now if the height is 0 */
> -if (Height <= 0) return;
> -
> -/* Set more weird values */

[ros-dev] Concerning regedit r47251: inform the user that search is complete

[Gregor Schneider]

Hi Michael,

there is no need to hardcode the messagebox output language to english.
In the resource files a string exists for what you're doing:
IDS_FINISHEDFIND (probably already loaded into a string in the code
somewhere).

Thanks,
Gregor
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] DecompressBitmap / Decompress4bpp / Decompress8bpp

[Gregor Schneider]

Hi Love,

your concern is correct, we're wasting cycles here. On the other hand, as
pointed out in the other RLE discussion, this code is a temporary solution.
We incorrectly decode RLE bitmaps to be able to process them with our
standard blitting routines. Low level RLE support for DIBs does not exist at
the moment. Same for JPEG and PNG formats.
Surprisingly everbody seems to be quite hot about RLE bitmaps recently,
considering we use exactly _ONE_ RLE bitmap (I know of) in ReactOS.

Concerning using an internal format: let's assume we got three 8bpp surfaces
(source, destination, pattern), which are quite big pending for a raster
operation. You would convert these three to another format like 32bpp,
process them and convert back? For these three surfaces the memory need for
processing is increased by a factor of 4 and performance is obviously bad
too. That's not an option considering that Starcraft for example spends most
of the time in DIB routines, highlighting that our current approach is not
even fast enough. Why decrease performance even further? Standard DIB access
functions to access all DIB formats exist, why not use them? The same
applies for our alpha blending approach. I have no clue if it would be
beneficial for fonts, but I doubt it.

Best regards,
Gregor

2010/5/9 Love Nystrom 

> Hi guys,
>
> Sorry for barging in on a discussion about code that's not on my desk,
> but looking at your code there is something I want to point out.
>
> Graphics code need to be *fast*, that's a primary consideration,
> so I'm taken aback when I look at your inner bit expansion loop.
> This is horrible from a standpoint of performance.
>
>length = (*bits++) >> shift;
>>   if (length)
>>   {
>>   c = *bits++;
>>   while (length--)
>>   {
>>   if (x >= width) break;
>>   temp = UncompressedBits + (((height - y) * Delta) + x);
>>   x++;
>>   *temp = c;
>>   }
>>   }
>>
>
> You're recomputing the start of the bit-run for every pixel you emit,
> when you should move that calculation out of the inner loop to get
> high performance. Graphics code is not the arena where you can be lazy
> and hope that the optimizer will make your inefficient code faster.
> At the very least You ought to write it something like this:
>
>length = (*bits++) >> shift;
>>   if (length)
>>   {
>>   c = *bits++;
>>   if (x + length > width) {
>>   // RLE encoding error - Bit-run exceeds width
>>   length = width - x;
>>   }
>>   temp = UncompressedBits + ((height - y) * Delta);
>>   x += length; // precompute finishing x
>>   while (length--)
>>   {
>>   *temp++ = c;
>>   }
>>   }
>>
>
> As a sideline note I'd like to mention that it's standard practice
> in graphics libraries to use one unified bitmap format internally
> to make internal processing like alpha-blend or text rendering or
> whatever straight forward. The 32bit DIB format is quite suitable,
> even if it uses the most memory - Graphics never was cheap on memory.
>
>
> Just my penny to the pot
> Best Regards
> // Love
>
>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] test/fix building fastfat_new

[Gregor Schneider]

Indeed a header problem: the functions RtlLeftChild and RtlSplay should be
in Ntddk.h or Ntifs.h according to msdn info, the ntifs.h is included
through fastfat.h. The header work group probably know whats going on.

Greg

2010/4/22 Alexey Komarov 

> Hi.
>
> Can somebody test/fix building fastfat_new? It seems, that it's problem
> with headers.
>
>
> Log:
>
> [CC]   drivers\filesystems\fastfat_new\fastio.c
> [CC]   drivers\filesystems\fastfat_new\fcb.c
> cc1.exe: warnings being treated as errors
> drivers\filesystems\fastfat_new\fcb.c: In function 'FatFindFcb':
> drivers\filesystems\fastfat_new\fcb.c:85: error: implicit declaration of
> functio
> n 'RtlLeftChild'
> drivers\filesystems\fastfat_new\fcb.c:85: error: assignment makes pointer
> from i
> nteger without a cast
> drivers\filesystems\fastfat_new\fcb.c:90: error: implicit declaration of
> functio
> n 'RtlRightChild'
> drivers\filesystems\fastfat_new\fcb.c:90: error: assignment makes pointer
> from i
> nteger without a cast
> drivers\filesystems\fastfat_new\fcb.c:95: error: implicit declaration of
> functio
> n 'RtlSplay'
> drivers\filesystems\fastfat_new\fcb.c:95: error: assignment makes pointer
> from i
> nteger without a cast
> drivers\filesystems\fastfat_new\fcb.c: In function 'FatInsertName':
> drivers\filesystems\fastfat_new\fcb.c:904: error: implicit declaration of
> functi
> on 'RtlInitializeSplayLinks'
> drivers\filesystems\fastfat_new\fcb.c:946: error: implicit declaration of
> functi
> on 'RtlInsertAsLeftChild'
> drivers\filesystems\fastfat_new\fcb.c:963: error: implicit declaration of
> functi
> on 'RtlInsertAsRightChild'
> drivers\filesystems\fastfat_new\fcb.c: In function 'FatRemoveNames':
> drivers\filesystems\fastfat_new\fcb.c:993: error: implicit declaration of
> functi
> on 'RtlDelete'
> drivers\filesystems\fastfat_new\fcb.c:993: error: assignment makes pointer
> from
> integer without a cast
> drivers\filesystems\fastfat_new\fcb.c:1002: error: assignment makes pointer
> from
>  integer without a cast
> make.exe: *** [obj-i386\drivers\filesystems\fastfat_new\fcb_fastfatn.o]
> Error 1
>
> WBR, Alexey Komarov.
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diff]rev 46907.gschneider[SHELL32] - Simplify checks for success of ShellExecuteEx

[Gregor Schneider]

Hi Victor,

you are perfectly right here, the situation is complicated. In my commit msg
I provided a link, which specifies the following behaviour:
*
*

hInstApp HINSTANCE
[out] If SEE_MASK_NOCLOSEPROCESS is set and the ShellExecuteEx call
succeeds, it sets this member to a value greater than 32. If the function
fails, it is set to an SE_ERR_XXX error value that indicates the cause of
the failure.

That made me think: what happens to this field if the ShellExecuteEx call
succeeds and the flag SEE_MASK_NOCLOSEPROCESS is not set? Since this check
was thought to forward the actual result of the execution i switched to a
simpler and (in my eyes) more reliable code. Plus the original code did not
use the flag noted in the specification.
The link you provided on the other hand makes it look like ShellExecuteEx
always sets this field indendent of any flags passed to the function.

To find out the truth one would have to write test cases. It might well be
that the implementation we use is partially incorrect. Especially when
looking at testman (it works again :-O ) @ shell32_winetest shlexec which
still has some failures.

Greg


2010/4/19 victor martinez 

>  Hi, i have been giving a look to this patch and i have some doubts(just
> learning :) )
> The code is:
> @@ -1298,8 +1298,8 @@ static HRESULT WINAPI
> ICPanel_IContextMenu2_InvokeCommand(
> sei.hwnd = lpcmi->hwnd;
> sei.nShow = SW_SHOWNORMAL;
> sei.lpVerb = L"open";
> -   ShellExecuteExW(&sei);
> -   if (sei.hInstApp <= (HINSTANCE)32)
> +
> +   if (ShellExecuteExW(&sei) == FALSE)
>return E_FAIL;
>
>
> MSDN says that if ShellExecuteExW fails it sets hInstApp to a value lower
> than 32 and,also, returns FALSE.
> (MSDN: 
> http://msdn.microsoft.com/en-us/library/bb762154(VS.85).aspx)
> So both lines of codes(buggy and patched) are,at first sight,doing the
> same.Just using a different way.
> The Commit says:
> - Simplify checks for success of ShellExecuteEx, field hInst may be an
> unreliable indicator according to
> http://msdn.microsoft.com/en-us/library/bb759784%28v=VS.85%29.aspx
>
> Why is it unreliable? :) I am not saying it is reliable, just that i dont
> find the reason there...my skills are limited.. :(
> I have just found: "Although hInstApp is declared as an HINSTANCE for
> compatibility with 16-bit Windows applications, it is not a true HINSTANCE.
> It can be cast only to an int and compared to either 32 or the following
> SE_ERR_XXX error codes ".
>
> So my question is: Is the Bug in the cast to (HINSTANCE) instead to (INT)?I
> mean,do this solve the bug too?:
> -   if (sei.hInstApp <= (HINSTANCE)32)
> +   if ((INT)sei.hInstApp <= 32)
>
> As you see i am just learning, so thanks in advance.
> And yes, i prefer the new way that patch is using.Using the returned the
> value seems much more logic than using a "collateral damage". :)
> Btw, thanks Gregor for your hunting-fixing week ;)
>
>
> --
> Tus datos personales, más seguros con Internet Explorer 8. ¡Descárgatelo
> gratis!
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Regressions and bugs

[Gregor Schneider]

Looks like Gabriel did a bugzilla attack too.

I'd like to add some comments: i've also been working the bug list of a
humble 600 items up and down, mainly addressing the easy visual and
configuration issues. See http://cia.vc/stats/author/gschneider.

I've skipped generelly skipped big feature enhancements and avoided explorer
bugs (explorer_new) and win32 subsystem issues (arwinss).

Current explorer bugs are fixable, but the effort is wasted if explorer_new
ever replaces the current one. Any plans, suggestions, ideas concerning it's
completion?

Concerning open bugs: i got incomplete/experimental patches in my tree for
5045 Charmap.exe: Copy Field Uses Default font.
3148 Properties for display with monitor
4008 ProgramFiles environment variable is not set (Creation of environment
variables seems to be a big problem. We need some research who sets which at
which point in time)

Summed up: Bugzilla needs YOU!
In case you are in doubt: we've got 33 unattended bz patches and probably
more hiding in dark places.
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Spanish translation for the new log off confirmation dialog (bug 1494, revision r46722)

[Gregor Schneider]

Hi,
I just commited it in r46731, mere seconds before you wrote this email.

Best regards,
Gregor Schneider

2010/4/5 Javier Agustìn Fernàndez Arroyo 

> @DosX,
>
> hi, i updated bug #1494 with the spanish translation updated...
>
> translation URL is http://www.reactos.org/bugzilla/attachment.cgi?id=4882
>
> hope its correct :)
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Arwinss presentation

[Gregor Schneider]

Now that I understand the driver concept behind arwinss I think that arwinss
is the right approach for the project.
Looking at the current development approach win32 user and kernel components
will not be finished anytime soon and will probably never work 100%. We're
just missing specialised developers to achieve that.
Furthermore mixing Wine and ReactOS codes on function level like done in
those components complicates matters dramatically and consumes energies that
could be used in better ways.

Summing that up: I like the idea, should indeed be a big push for
application compability.
Actually I'm surprised we don't see a big controversial discussion around
this idea like everyone expected.

Concerning the picture on page 25 of the presentation: I remember having
seen the start menu side bar cropped like this before in some of my tests.
Was it StretchDIBits, or rather StretchBlt? I'll find out.

Best regards,
Gregor Schneider

P.S: Quite interesting how the press judged this announcement: "ReactOS
about to restart" is what I read today on a german technology news page.
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [ekohl] 45020: Removed outdated email addresses.

[Gregor Schneider]

I guess we could even live without the developer names in the file header.
Just inserting "ReactOS dev team" or similar would save a lot of useless
discussions. Current name listings are normally incomplete anyways and only
a SVN blame can reveal the real authors. For credits and E-Mail contacts
there's a credits file.

2010/1/10 Alwyn Tan 

> Hello Aleksey. Would be useful to reach the developers if anybody wants to
> ask about the code, or ReactOS, or their development in general.
>
>
> On Sun, Jan 10, 2010 at 12:43 PM, Aleksey Bragin wrote:
>
>> What do you all think about developer's email in source code? Is
>> there a need for it at all there?
>>
>> WBR,
>> Aleksey.
>>
>> On Jan 10, 2010, at 1:43 AM, ek...@svn.reactos.org wrote:
>>
>> > Author: ekohl
>> > Date: Sat Jan  9 23:43:16 2010
>> > New Revision: 45020
>> >
>> > URL: http://svn.reactos.org/svn/reactos?rev=45020&view=rev
>> > Log:
>> > Removed outdated email addresses.
>> > Modified: trunk/reactos/ntoskrnl/ke/queue.c
>> > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/
>> > queue.c?rev=45020&r1=45019&r2=45020&view=diff
>> > ==
>> > 
>> > --- trunk/reactos/ntoskrnl/ke/queue.c [iso-8859-1] (original)
>> > +++ trunk/reactos/ntoskrnl/ke/queue.c [iso-8859-1] Sat Jan  9
>> > 23:43:16 2010
>> > @@ -5,7 +5,7 @@
>> >   * PURPOSE: Implements kernel queues
>> >   * PROGRAMMERS: Alex Ionescu (alex.ione...@reactos.org)
>> >   *  Gunnar Dalsnes
>> > - *  Eric Kohl (ek...@rz-online.de)
>> > + *  Eric Kohl
>> >   */
>>
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] ReactOS 0.3.11 source broken?

[Gregor Schneider]

The source for release versions differes slightly from the SVN source.
Still the releases are built from release source, so it should compile with
the appropriate RosBE version.
What type of error did you get?

2009/12/21 Jose Catena 

> This is very strange, the published source for 0.3.11 causes compile errors
> here. I compiled without problems all recent versions from svn up to 44678.
> The published source must not be the one used to compile the release, or
> something really weird is happening.
> I thought you wanted to know.
>
>
> Jose Catena
> DIGIWAVES S.L.
>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [janderwald] 44644: [SETUPAPI] - Implement SetupDiInstallDeviceInterfaces, SetupDiCreateDeviceInterfaceRegKeyW which are required to store device specific information

[Gregor Schneider]

Good one in r44649, but I guess Hervè was actually concerned about this
line:

DeviceInterfaceData.Reserved = (ULONG_PTR)DevItf;

(It also stores the pointer to the freed structure.)

2009/12/18 Johannes Anderwald 

> Hervé Poussineau schrieb:
> > janderw...@svn.reactos.org a écrit :
> >
> >
> > Seems like you're keeping in DeviceInterfaceData.Reserved a pointer to a
> > deleted structure... Is it intentional?
> >
> Definitely not ;)
>
> Thanks
> Johannes Anderwald
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [janderwald] 44644: [SETUPAPI] - Implement SetupDiInstallDeviceInterfaces, SetupDiCreateDeviceInterfaceRegKeyW which are required to store device specific information

[Gregor Schneider]

Most likely not, MSDN mentions "do not use" concerning this field.
Ref: http://msdn.microsoft.com/en-us/library/ms793004.aspx

2009/12/18 Hervé Poussineau 

> janderw...@svn.reactos.org a écrit :
> > Author: janderwald
> > Date: Fri Dec 18 05:37:15 2009
> > New Revision: 44644
> >
> > URL: http://svn.reactos.org/svn/reactos?rev=44644&view=rev
> > Log:
> > [SETUPAPI]
> > - Implement SetupDiInstallDeviceInterfaces,
> SetupDiCreateDeviceInterfaceRegKeyW which are required to store device
> specific information
> >
> > Modified:
> > trunk/reactos/dll/win32/setupapi/devinst.c
> > trunk/reactos/dll/win32/setupapi/interface.c
> > trunk/reactos/dll/win32/setupapi/setupapi_private.h
> >
> >
> [...]
> > +
> > +InsertTailList(&devInfo->InterfaceListHead, &DevItf->ListEntry);
> > +
> > +memcpy(&DeviceInterfaceData.InterfaceClassGuid,
> &DevItf->InterfaceClassGuid, sizeof(GUID));
> > +DeviceInterfaceData.cbSize = sizeof(SP_DEVICE_INTERFACE_DATA);
> > +DeviceInterfaceData.Flags = DevItf->Flags;
> > +DeviceInterfaceData.Reserved = (ULONG_PTR)DevItf;
> > +
> > +hKey = SetupDiCreateDeviceInterfaceRegKeyW(DeviceInfoSet,
> &DeviceInterfaceData, 0, KEY_ALL_ACCESS, NULL, 0);
> > +HeapFree(GetProcessHeap(), 0, DevItf);
> > +if (hKey == INVALID_HANDLE_VALUE)
> > +{
> > +return FALSE;
> > +}
> > +
> >
> Seems like you're keeping in DeviceInterfaceData.Reserved a pointer to a
> deleted structure... Is it intentional?
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Improving our procedure

[Gregor Schneider]

That's exactly what I was talking about:
for me it means 95% copy and paste amd still takes quite a lot of time since
it has to be organised into modules. Thats why I mentioned >boring< and like
the idea of a script to do that. Thanks for using caps and acting immature
to point that out.

2009/12/15 Alex Ionescu 

> You guys with your "Creating a changelog is boring" are really really
> acting immature and irresponsible.
>
> I, considered the most "arrogant", "asshole" and "abrasive" person of this
> project, who would "never low myself" to writing a changelog after
> "Rewriting the kernel" ALWAYS FOUND THE F*CKING TIME TO SIT DOWN FOR AN HOUR
> AND DO MY LOG.
>
> How HARD can it possibly be, when, no offense, most of you do 1/5th of the
> number of commits I used to do?
>
> Use SVN to grab the commit log, use a regexp to remove non-YOURUSERNAMEHERE
> logs, and if you have BEEN WRITING GOOD LOGS FOR EACH COMMIT, you can pretty
> much COPY PASTE THAT LIST, and then organize it into modules.
>
> Oh yeah, to those of you whose commit logs have been "fix a bug.", well
> SUCK IT UP.
>
>  On 2009-12-15, at 10:11 AM, Zachary Gorden wrote:
>
> The person who said it was a mess was me, and the last time around due to
> the inconsistent commit message formats used by different devs it did create
> one.  And as one of the people responsible for formatting the changelog, my
> workload increased due to it.  Which was why I wanted a guideline/template
> ready for devs to use in their commits before we tried using the script
> again.  And as you're likely aware, I haven't been on consistently lately
> due to schoolwork so the final decision on the format is unknown to me.
>
> On Tue, Dec 15, 2009 at 8:50 AM, victor martinez wrote:
>
>> :)
>> Nice to see opinions, i wasnt aware about Matthias script. Can it be set
>> to make a Changelog by author? I mean, not processing all the commit
>> messages but just from those commiters that want to use it?I think there are
>> devs that doesnt know about the existence of this script. :)
>> If more and more devs joins this project, then Changelog is going to be a
>> pain in the...so automated tools will be a must.
>>
>>
>>
>> --
>> 49 habitantes, 49 expertos en Windows 7. Así es Sietes, 
>> ¡Visítalo!
>>
>> ___
>> Ros-dev mailing list
>> Ros-dev@reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>  Best regards,
> Alex Ionescu
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Improving our procedure

[Gregor Schneider]

I already asked why it wasn't used for 0.3.11 CL before starting my parts
manually. Somebody answered it is because of the mess it caused - but I
can't remember any mess nor the person answering me.

2009/12/15 Matthias Kupfer 

> Hi,
>
> just for your information, I have already written a script and it's already
> available in trunk (/trunk/tools/changelog/autocl.py), but Aleksey decided
> to
> make the ChangeLog manually. Of course the script can't do any magic, but
> it
> was intended to setup up a ChangeLog-base for manual adjustments with the
> great advantage that nothing will be forgotten. Maybe we can improve the
> script to fit it to our needs and make it as much flexible as possible, but
> nevertheless, we have to give it a chance to judge...
>
> Matthias
>
> --
> Matthias Kupfer  phone +49 (0) 371 236 46 52
> Wilhelm-Firl-Straße 21   mobile +49 (0) 160 859 43 54
> 09122 Chemnitz, Germany
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Improving our procedure

[Gregor Schneider]

Some thoughts on this from my side:

Creating the changelog is boring and time consuming. We should enforce some
kind of commit message regulation that allows to automate changelog creation
as discussed earlier. Opening changlogs early sounds good, but we should be
sure which kind of release we're aiming for (0.3.12 or 0.4?). Or just name
it "next changelog" and rename it later.
Why do we have two release engineers if only Colin does Releases?

Certain changelog entries are still missing entries as it seems (hi Jim!).
I'll have look this evening concerning your entries Victor.

Why would anyone object using a script for creating a changelogs and on the
other hand not create his entries manually? I don't see any reasons against
using a script (except for missing commit message guidelines - but that can
change).

Gregor

2009/12/15 victor martinez 

> Hi,
> This is incredible. I can understand a delay in a release because fixing
> Blockers, i can understand a delay because we are afraid of "2012" movie.But
> i can not understand why the Changelog is not made!!. On 3rd of November
> Aleksey sent an email saying a Blocker was present to release 0.3.11, this
> means that on 3rd of November a full Changelog should have been done and
> just  2 lines (explaining the Fix,if needed) should have been added
> afterwards. But the fact is that the Blocker has been solved more than one
> week ago, that we are still waiting for changelog to be done(after more than
> a month) and that the binaries are stored in SF waiting indefinitely to link
> them.
> So this strikes again, what is happening with Changelogs?What happens if
> noone wants to write his Changelog?Are we going to stay here waiting it
> indefinitely?Is our actual procedure correct?Or is it not practical?How can
> we shorten the time for a release?What happens if one of the Steps before
> releasing (like Changelog Step) is not properlly done?Do we have a PlanB?
>
> Let´s review our Teorical steps before a release and finding Bottlenecks as
> i do in my work:
> 1) Coding Time.During this time Devs creates ReactOS code.Since 0.3.9 also
> the GoldenApps and CandidateApps are being tested during this time in
> regular basis to reduce the possible Blockers.
> 2) Choosing Minute. An ISO is chosen as Candidate. Doubts: When the
> Candidate is chosen?Following which criterias?Why sometimes we take an ISO
> after one month and other times after 2 months?
> 3) Colin creates a Pre-release ISO.
> 4) Colin creates the 0.3.XX wikipage.Tests begins and Changelog begins to
> be written.
> 5) Performing Testing on Candidate. It usually takes less than a week, and
> thanks to previous testings in Coding Time, there are less Blockers each
> time.
> 6A) Blocker found. If a Blocker is found, a regression testing begins(if
> needed) and a patch/hack is made.GoTo 7
> 6B) Blocker not found. prerelease ISO is released as definitive.END.
> 7)Patch is added to release branch, Colin creates a second RC and testers
> perform a full test focusing in the regression. Release.END.
>
> Let´s begin studying the 0.3.11 case.
> Step 1 was done correctly.We have devs still working on ROS.great!
> Step 2 was a CHAOS. I have been asked to select first an ISO before asking
> Colin to make a prerelease ISO of it. Testing that first ISO we found the
> Vmware regression but it took a little(more than a month to fix it) so we
> select a different ISO and we performed a full testing (again) before asking
> Colin to create a prerelease.
> Changing the ISO is not inside the Teorical steps,but since the patch for
> Vmware wasnt made and we had time it didnt suppose really a lose of time.
> Step 3.First bottleneck. It took a little to contact with Colin,because he
> was busy with RL, so we had to wait him to create a Branch,include the
> reverts and create the prerelease.If I recall correctly it took more than a
> Week. Without the prerelease done is impossible to test anything.We should
> have an alternative to Colin in case Colin is busy with RL.We dont have a
> PlanB for this situation.
> Step4. Colin creates the Wikipage.
> Step5.Test begins but Changelog didnt begin to be written, it has been
> asked twice via ML, and zillions via IRC. Currently we are waiting for
> having it complete.
>
> And now second bottleneck:
> In 0.3.11 case,Blockers were solved BEFORE prerelease was made, so when
> Colin uploaded the prerelease iso it doesnt have any Blocker and it is ready
> to be released.And then the bottleneck comes:Changelog. Changelog can be
> created without hurry if we are in step 6A(a Blocker found) but in case 6B
> (as 0.3.11 prerelease is) you dont have real time to create it. When a
> Blocker is found,Changelog can be created during the extra time of
> regtesting+finding a patch+adding to branch+creating a new iso+performing
> again all the Tests, (this extra time is usually 4 weeks). But when non
> Blocker is found in Step6, Changelog stops our release.You cant made a
> proper Changelog of 2 months ch

Re: [ros-dev] [ros-diffs] [gschneider] 44543: [ntoskrnl] - The field ZeroInit should be initialized to zero - do that by assigning the message type directly - Fixes the hanging ntdll port winetest (it

[Gregor Schneider]

After I changed all occurences to the wanted behaviour in r44549 - sure.
Thats how it looked like before the change:
http://git.reactos.org/?p=reactos.git&a=search&h=0fc25b028945a5595b9054294172554ec550bde2&st=grep&s=ZeroInit
(the git link i first posted used head as reference)

2009/12/13 Timo Kreuzer 

> Gregor Schneider wrote:
> > I'm pretty much sticking to the way it is done in most other places.
> > Ref:
> > http://git.reactos.org/?p=reactos.git&a=search&h=HEAD&st=grep&s=ZeroInit
> >
> I can only see
> "ApiMessage.h.u2.ZeroInit = 0"
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [gschneider] 44543: [ntoskrnl] - The field ZeroInit should be initialized to zero - do that by assigning the message type directly - Fixes the hanging ntdll port winetest (it

[Gregor Schneider]

I'm pretty much sticking to the way it is done in most other places.
Ref:
http://git.reactos.org/?p=reactos.git&a=search&h=HEAD&st=grep&s=ZeroInit


2009/12/12 KJK::Hyperion 

> gschnei...@svn.reactos.org wrote:
> > - The field ZeroInit should be initialized to zero - do that by assigning
> the message type directly
>
> please do this by zero-initializing ZeroInit instead. Don't play with
> unions
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] DVCS again [was: Trunk locked]

[Gregor Schneider]

I had similar ideas recently. Working with tortoisegit on Wine for one of my
patches felt weird first, but being able to commit changes locally and is
quite powerful. At first I wondered what it could be good for, but the
locked trunk showed me just that.

Keeping a history of patches which include commit messages and which even
might work separated from others is awesome.
Concerning the tortoiseGit GUI I have to agree that it's not as intuitive as
the SVN counterpart, but one always needs a certain time to get used to new
tools.

Big problem with those systems is the final checkin into the master branch.
The one person managing patch mails and applying all patches has the most
boring job ever. Furthermore this person has to have A LOT of time. No clue
which other concepts are supported by those two tools.

I remember seeing a GIT presentation by Torvalds at some Google event where
he introduced the Linux kernel "team" organisation.
Several maintainers who get patches for their area and himself being the
bigboss just copying their repos and not doing any patches at all. When a
checkout from a maintainer failed for him he just dropped it and took
anotherone.

Pretty cool tree like structure sounds possible here, but the concept of
maintainers or rather development areas/teams doesn't seem to work for
ReactOS. From the time when I started following ReactOS I proposed it
severeal times, but noone seems to be interested.

Gregor

2009/11/29 Colin Finck 

> Zachary Gorden wrote:
> > This is common practice before a release and has been done for at least
> > the last year or so.
>
> You make it sound like locking the whole trunk and making the majority of
> developers unable to work properly is a state we want to keep.
> Of course, this has mostly been done due to having no alternatives when
> using Subversion and our urgent need to fix these blockers. But still, it's
> generally the worst possible action I can think of when it comes to
> collaborating on Open-Source projects...
>
> ... which raises the question about switching to a distributed version
> control system for me again.
>
> While Subversion has proven to be a viable solution for most of our needs,
> we still have to cope with its drawbacks from time to time.
> The major ones I can think of include:
>
>  * Build breakages in trunk prevent other developers from working.
>
>Although some devs might have already get used to occasional build
>breaks, this could become a bigger problem when, for example, two
>developers constantly commit to a common component and update their
>working copies afterwards.
>They would immediately be forced to stop their work and wait for a fix,
>when a build break occurs, even if it's lying in a completely different
>component.
>
>With Git or Mercurial, we could make wholly different workflows
>possible here. A better one might be that each developer only works on
>their own branches (which can be local and/or remote).
>Optionally, two or more developers working on the same component could
>also commit to a common branch, but still independent of the trunk or
>master branch. If one needs stuff from a different branch, he can
>easily merge single commits or fetch all changes from a branch.
>
>Though SVN of course also provides branches, merging is far away from
>being a transparent and trivial task there. I guess that the devs, who
>often deal with our SVN branches, can confirm this.
>Git or Mercurial solve this task way better.
>
>
>  * Not all commits in trunk are well-tested and easily make it unstable.
>
>The recent locking of trunk again showed that it's still a place where
>every trusted dev can, roughly speaking, commit whatever he wants.
>It should be obvious that this leads to unexpected problems from time
>to time.
>Many people might also well remember the GL case, when the drastic
>action of limiting one developer's SVN write access to branches was
>done to prevent him from committing possibly problematic stuff to
>trunk.
>
>Using the branch workflow as described above would circumvent both
>problems and even make trunk an unattractive place to work on.
>If people have their own branches, where they can do everything they
>want, to prepare a big change (e.g. that network locking rewrite),
>nobody should ever need to work directly on trunk again.
>We would just need to establish new rules or methods to get commits
>from the branches into the trunk/master branch. Maybe a combination of
>automatic and manual testing (depending on the situation) can help us
>here.
>
> Such problems will turn out to be more severe with the raising number of
> developers.
>
> While this topic has already been partly discussed last year, the
> comfortable Windows support (= TortoiseSVN-like shell extensions) for both
> Git and Mercurial was still in very early stages of development at that
> time.
> T

Re: [ros-dev] Trunk locked

[Gregor Schneider]

Aleksey announced via IRC that trunk is open for commits again.


2009/11/28 Ged Murphy 

> I assume trunk is now unlocked??
> There's been no mention of it but commits have restarted
>
> -Original Message-
> From: ros-dev-boun...@reactos.org [mailto:ros-dev-boun...@reactos.org] On
> Behalf Of Aleksey Bragin
> Sent: 17 November 2009 21:35
> To: ReactOS Development List
> Subject: [ros-dev] Trunk locked
>
>Hello,
> the trunk of our SVN server has been locked to prevent even more
> regression from entering the tree.
>
> So far, after more than 3 weeks after I filed the bug report and not
> including all previous time when people were complaining about rapps
> which can't download anything at all - either hangs or crashes, I see
> that now even PCNet network card is being recognized in my VMWare
> Workstation 6.5.
>
> Trunk is writable right now by members of the bugfix team only,
> that's so far Cameron (because he is the one supposed to fix
> networking) and me. If someone volunteers to fix any of the existing
> regressions, please let me know on irc/email, I'll include you into
> the bugfix team.
>
>
> Thanks for understanding, and patience. My patience is over.
>
> WBR,
> Aleksey Bragin.
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] I'm back

[Gregor Schneider]

Hi and welcome back,

I'm currently busy with my Masters thesis and that will take a lot more
time. It's also related to Software Design and needs my complete focus.
Therefore no ReactOS developments from me atm.

Except from a lot of experimental patches I still got one gimmick in my
tree: a Spider Solitaire clone developed for fun a month ago, based on the
catch22 cardlib our solitaire uses as well. The only important thing it
lacks is a good icon. Couldn't find anything suitable within the Tango icon
set. Found one nice icon on the net, but the author doesn't answer my mails.
If anyone feels like drawing a nice spider icon, feel free to do so and drop
me a line.


Regards,

G. Schneider
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Webtest manager

[Gregor Schneider]

>From what I know the current address is http://backend.reactos.org/testman/.
The server experienced some problems with virtual machine resource freeing
Christoph recently addressed.

Best regards
Gregor
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [gschneider] 42402: asctime/ctime: Check for too low input time, fixes one msvcrt time winetest

[Gregor Schneider]

ctime and asctime handle this differently:
-asctime allows years from 1900, since it offsets the years. Values given
supplied that (negative) let the function output garbage. Ref:
http://www.cplusplus.com/reference/clibrary/ctime/tm/
-ctime gets the number of seconds passed and converts these to a struct
which is passed to asctime in this implementation. The first second is
defined to be on 1st jan 1970. Ref:
http://www.cplusplus.com/reference/clibrary/ctime/time_t/

Anyway I'll most likely test tkreuzer's crt time implementation from the
64bit branch. If if works out good it'll replace the current crt time code
soon.

Best regards
G. Schneider
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] [ros-diffs] [gschneider] 42402: asctime/ctime: Check for too low input time, fixes one msvcrt time winetest

[Gregor Schneider]

Hi,

I just checked: ctime and asctime have a different behaviour when it comes
to parameter checks, although they work on the same buffer. I'll address
this soon.
Most param  checks are missing indeed, but they'll be added one after
another. I'm just starting on that. The only real life problem with the code
that I could find is that mktime produces a time that is one or two hours
off.


Best regards

Gregor Schneider
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev