This looks great, but I hope you're aware of the limitations of DllMain.
If the test gets more complex, it might be better to do a separate
CreateRemoteThread call on an exported function after the dll has been
loaded.
Although I guess as long as things work, this is fine ;)
(maybe this is related to the SEH issue you mention in the next commit,
not sure)
On 2015-06-08 19:15, cfinck(a)svn.reactos.org wrote:
> [LOCALSPL_APITEST]
> Write an API-Test for localspl.dll. As the original localspl.dll from Windows Server 2003 relies on proper initialization inside spoolsv.exe, we cannot test it standalone as usual.
> +// Running the tests from the injected DLL and redirecting their output to the pipe.
> +BOOL WINAPI
> +DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
> +{
> + char szTestName[150];
> + DWORD cbRead;
> + FILE* fpStdout;
> + HANDLE hCommandPipe;
> + int iOldStdout;
> +
> + // We only want to run our test once when the DLL is injected to the process.
> + if (fdwReason != DLL_PROCESS_ATTACH)
> + return TRUE;
Quick note: Files that get embedded into binaries or put on the CD
should not use native EOL, but CRLF.
This applies e.g. to inf files, as well as text files that are
resources (which I believe is what these inis are?).
The idea is that in a perfect world the CD image build by a Unix
builder is identical to the one built by a Windows builder.
On 2015-06-06 20:27, akhaldi(a)svn.reactos.org wrote:
> [LAUTUS] Make the text files UTF-8 without BOM, and convert them to UTF-16 LE at compile time. Remove the now unneeded application/octet-stream type property and set native EOL one. CORE-9770
> Propchange: trunk/reactos/media/themes/lautus.msstyles/textfiles/NormalNormal.INI
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
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