Hi,
The names for our builders / testers don't seem to be optimal to me. And
since they seem to be sorted in the waterfall display alphabetically
now, I suggest renaming them in the following way:
Build_GCCLin_Debug
Build_GCCLin_Release
Build_GCCWin
Build_MSVC_x64
Build_MSVC_x86
Test_KVM
Test_VBox
Test_VMW
Test_VMW_Hybrid
Test_WHS
This way it is much more consistent, limited to actually useful
information and would sort them nicely with builders left and testers right.
Regards,
Timo
Dear all,
We have proceed to a complete reimplementation of authentication server
which serves Jira & Fisheye. The purpose is to rely on something
maintained and stable.
It should not change anything for you on daily usage. 58 accounts have
been left out and will not be able to connect to Jira due to
incompatible account name (using invalid chars). If you happen to be
incapable of log in, please contact me so that I can rename your account.
New accounts cannot be created with such invalid chars any longer.
As a side note, this was a major blocker for our upgrade to Jira 6. If
we do not spot anything wrong with our new authentication mechanism,
then, then the upgrade to Jira 6 should happen in the next days.
With my best regards,
--
Pierre Schweitzer <pierre(a)reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Hi all,
In order to verify the exact behaviour of localspl.dll on Windows Server
2003, I'm trying to write an API-Test for it. This is no problem for
winspool.drv or even the Print Processor functions of localspl.dll, but
its Print Provider functions pose some serious problems:
* You get a table of function pointers by calling InitializePrintProvidor.
* Instead of just handing over the pointers, this function first calls
many undocumented ones from spoolss.dll, including CacheAddName,
CacheCreateAndAddNode, GetServerPolicy, SplInitializeWinSpoolDrv,
SplIsUpgrade.
* Out of these undocumented functions, GetServerPolicy is the most
problematic one, because it itself relies on a function pointer given by
spoolsv.exe to spoolss.dll in an initialization function. My API-Test is
not spoolsv.exe, so I don't initialize spoolss.dll the same way. Thus,
GetServerPolicy will fail and InitializePrintProvidor as well.
* For now, I worked around this problem by stubbing these functions in
my spoolss.dll. I.e., GetServerPolicy just returns TRUE there and I get
further.
* On top of this, InitializePrintProvidor also makes use of
RevertToPrinterSelf and ImpersonatePrinterClient. To let these functions
succeed, the current thread actually needs to impersonate a user. For
now, I worked around this problem by doing:
OpenProcessToken(GetCurrentProcess(), TOKEN_DUPLICATE, &hToken);
DuplicateToken(hToken, SecurityImpersonation, &hDup);
ImpersonateLoggedOnUser(hDup);
before calling InitializePrintProvidor.
* Finally, this lets InitializePrintProvidor succeed and it gave me the
table of function pointers.
Unfortunately, even simple query functions like fpEnumPrinters do a
RevertToPrinterSelf and then expect to be in the SYSTEM context of
spoolsv.exe. When my API-Test was just run in a usual Administrator user
context under Windows Server 2003, fpEnumPrinters didn't succeed.
For now, I worked around this problem by running my test program as a
service in the SYSTEM context.
With all these problems presented, can you think of any way how I can
now write a reliable API-Test for localspl.dll that could be run
regularly under Windows Server 2003 and ReactOS?
One idea would be to load the system spoolss.dll and then rewire the
GetServerPolicy import to a function that just returns TRUE all the time.
Still then, I have the problem that my API-Test would need to be run in
the SYSTEM security context.
Creative ideas are welcome! :)
Cheers,
Colin
Hey guys,
as some of you might have seen already we now have two copies of the more and more increasing RAPPS DB in trunk. This is:
a) Absolutely unnecessary and does only result in one thing, two differing DBs
b) Shows even more that it’s not useful to have it in trunk at all.
Because of this I start a vote now to get your opinion in completely removing the RAPPS DB from trunk into a subtree like done for many other things, too.
What do you think?
Greetings
Daniel Reimer
Gesendet von Windows Mail
Interesting that the wine code doesn't check for NULL at HeapAlloc at all
- could these be submitted to wine?
Additionally, at least one HeapAlloc isn't checked also in our build:
piDx = HeapAlloc(GetProcessHeap(),0,sizeof(INT) * (*count));
Perhaps a
#ifdef __REACTOS__
if (piDx == NULL)
{
return FALSE; //Not sure about this, just looked at the diff ;)
}
#endif
would be usefull there.
Best regards,
Michael Fritscher
> Author: akhaldi
> Date: Sat May 30 17:14:16 2015
> New Revision: 67974
>
> URL: http://svn.reactos.org/svn/reactos?rev=67974&view=rev
> Log:
> [USER32] Sync edit.c with Wine Staging 1.7.37. CORE-9246
>
> Modified:
> trunk/reactos/media/doc/README.WINE
> trunk/reactos/win32ss/user/user32/controls/edit.c
>