Ros-dev

ros-dev@reactos.org

5791 discussions

Re: [ros-dev] [ros-diffs] [pschweitzer] 68137: [KERNEL32] Addendum to r68136: use appropriate define. Spotted by Thomas
by Timo Kreuzer 15 Jun '15

15 Jun '15

Am 14.06.2015 um 18:00 schrieb pschweitzer(a)svn.reactos.org: > Author: pschweitzer > Date: Sun Jun 14 16:00:27 2015 > New Revision: 68137 > > > - Proc = (1ULL << Processor) >> 0x20; > + Proc = (1ULL << Processor) >> MAXIMUM_PROCESSORS; This is effectively the same as "Proc = (Processor == MAXIMUM_PROCESSORS);" which is always 0. Timo

1 1

Re: [ros-dev] [ros-diffs] [cfinck] 68080: [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 st...
by Thomas Faber 14 Jun '15

14 Jun '15

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;

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 68051: [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...
by Thomas Faber 14 Jun '15

14 Jun '15

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 >

1 0

Name of builders/testers in buildbot
by Timo Kreuzer 14 Jun '15

14 Jun '15

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

4 4

Re: [ros-dev] [ros-diffs] [akhaldi] 68069: [OLE32_APITEST] Add test for IInitializeSpy. By Mark Jansen. See ROSTESTS-175 for more details.
by Thomas Faber 13 Jun '15

13 Jun '15

For future reference: (1) It's a bad idea to move something to a different file and edit it at the same time (2) Those constructor parameters really should be optional. The interface was trivial before, and it's a good idea to keep it that way. (I'm really only saying this because it broke the additional tests I had in my working copy :D) On 2015-06-08 13:05, akhaldi(a)svn.reactos.org wrote: > Added: trunk/rostests/apitests/include/unknownbase.h > URL: http://svn.reactos.org/svn/reactos/trunk/rostests/apitests/include/unknownb… > ============================================================================== > --- trunk/rostests/apitests/include/unknownbase.h (added) > +++ trunk/rostests/apitests/include/unknownbase.h [iso-8859-1] Mon Jun 8 11:05:35 2015 > @@ -0,0 +1,47 @@ > +#ifndef APITESTS_UNKNOWNBASE_H > +#define APITESTS_UNKNOWNBASE_H > + > +template<typename Interface> > +class CUnknownBase : public Interface > +{ > + LONG m_lRef; > + bool m_AutoDelete; > +protected: > + virtual const QITAB* GetQITab() = 0; > +public: > + > + CUnknownBase(bool autoDelete, LONG initialRef) > + : m_lRef(initialRef), > + m_AutoDelete(autoDelete) > + { > + } > + > + ULONG STDMETHODCALLTYPE AddRef () > + { > + return InterlockedIncrement( &m_lRef ); > + } > + > + ULONG STDMETHODCALLTYPE Release() > + { > + long newref = InterlockedDecrement( &m_lRef ); > + if (m_AutoDelete && newref<=0) > + { > + delete this; > + } > + return newref; > + } > + > + HRESULT STDMETHODCALLTYPE QueryInterface(REFIID riid, void** ppv) > + { > + return QISearch(this, GetQITab(), riid, ppv); > + } > + > + virtual ~CUnknownBase() {} > + > + LONG GetRef() const > + { > + return m_lRef; > + } > +}; > + > +#endif // APITESTS_UNKNOWNBASE_H

1 0

Changes in authentication for Jira
by Pierre Schweitzer 11 Jun '15

11 Jun '15

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.

4 7

PATCH: Get configure and host-tools building on arm again
by Steven Edwards 11 Jun '15

11 Jun '15

-- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

1 0

Writing an API-Test for localspl.dll
by Colin Finck 07 Jun '15

07 Jun '15

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

2 1

Gallium Nine?
by Mohamed MEDIOUNI 06 Jun '15

06 Jun '15

Can Gallium Nine be used instead of WineD3D?

1 0

Vote for removing rapps DB from trunk
by daniel.reimer＠reactos.org 01 Jun '15

01 Jun '15

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

4 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev