- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [ekohl] 63326: [NTOSKRNL] xHalIoReadPartitionTable: Only used non-container partition entries have a non-zero partition number.

by Pierre Schweitzer

Hey Eric, This fix unfortunately broke trunk. Our four testbots are red. Have a look here, for instance: http://build.reactos.org/builders/Linux_AMD64_1%20KVM-Test/builds/6442/step… Cheers, Pierre On 17/05/2014 14:55, ekohl(a)svn.reactos.org wrote: > Author: ekohl > Date: Sat May 17 12:55:06 2014 > New Revision: 63326 > > URL: http://svn.reactos.org/svn/reactos?rev=63326&view=rev > Log: > [NTOSKRNL] > xHalIoReadPartitionTable: Only used non-container partition entries have a non-zero partition number. > > Modified: > trunk/reactos/ntoskrnl/fstub/disksup.c > > Modified: trunk/reactos/ntoskrnl/fstub/disksup.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/fstub/disksup.c?r… > ============================================================================== > --- trunk/reactos/ntoskrnl/fstub/disksup.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/fstub/disksup.c [iso-8859-1] Sat May 17 12:55:06 2014 > @@ -1655,8 +1655,7 @@ > UInt32x32To64(GET_PARTITION_LENGTH(PartitionDescriptor), > SectorSize); > > - /* FIXME: REACTOS HACK */ > - PartitionInfo->PartitionNumber = i + 1; > + PartitionInfo->PartitionNumber = (!IsContainerPartition(PartitionType)) ? i : 0; > } > else > { > @@ -1667,7 +1666,6 @@ > PartitionInfo->PartitionLength.QuadPart = 0; > PartitionInfo->HiddenSectors = 0; > > - /* FIXME: REACTOS HACK */ > PartitionInfo->PartitionNumber = 0; > } > } > > -- Pierre Schweitzer<pierre at reactos.org> System Administrator ReactOS Foundation

11 years, 4 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 63135: Arch, please do not mix up ANSI vs. UNICODE string functions, do you?

by Aleksey Bragin

Speaking of that (1000s time), the proper way would be to convert everything to UNICODE. It would help. Regards, Aleksey Bragin On 03.05.2014 21:24, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Sat May 3 17:24:22 2014 > New Revision: 63135 > > URL: http://svn.reactos.org/svn/reactos?rev=63135&view=rev > Log: > Arch, please do not mix up ANSI vs. UNICODE string functions, do you? > > Modified: > trunk/reactos/base/applications/network/ftp/cmds.c > > Modified: trunk/reactos/base/applications/network/ftp/cmds.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/network/… > ============================================================================== > --- trunk/reactos/base/applications/network/ftp/cmds.c [iso-8859-1] (original) > +++ trunk/reactos/base/applications/network/ftp/cmds.c [iso-8859-1] Sat May 3 17:24:22 2014 > @@ -1303,13 +1303,13 @@ > > if (argc > 1) > { > - strncat(CmdLine, " /C", MAX_PATH - wcslen(Cmdline) - 1); > + strncat(CmdLine, " /C", MAX_PATH - strlen(Cmdline) - 1); > } > > for (i=1; i<argc; i++) > { > - strncat(CmdLine, " ", MAX_PATH - wsclen(Cmdline) - 1); > - strncat(CmdLine, argv[i], MAX_PATH - wsclen(Cmdline) -1); > + strncat(CmdLine, " ", MAX_PATH - strlen(Cmdline) - 1); > + strncat(CmdLine, argv[i], MAX_PATH - strlen(Cmdline) -1); > } > > StartupInfo.cb = sizeof( StartupInfo ); > >

11 years, 4 months

3
2
0 0

ReactOS' defragger "Fraginator" history

by Hermès BÉLUSCA - MAÏTO

Hi everybody! During some little maintenance of rosapps I was doing during some work pause, I wanted to know from where we found our still unused (until someone programs the defragmentation API :P) defragger called Fraginator. Since it doesnt contain any information about his initial author I tried to check into the SVN log, and I found that it was added in our codebase in 2006 by Ged: see the commit log http://svn.reactos.org/svn/reactos?view=revision <http://svn.reactos.org/svn/reactos?view=revision&revision=21411> &revision=21411 ; notice that the committer mentioned that [Fraginator] is pretty hard to come by on the net now. Nevertheless nothing is said about his author. However (!!) googling at fraginator defragger, I fell on this webpage, certainly written by the actual Fraginator author: http://blog.getpaint.net/2012/03/28/college-adventures-in-open-source-fragin ator-edition/ . In this blog entry you have the story of the Fraginator defragger! (if someone can add an entry, he/shes welcome). Nice reading! Hermès.

11 years, 4 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 63247: [DDK/XDK/NTOSKRNL/DRIVERS] Fix incompatible definition of a number of NTOSKRNL data imports. These imports are declared in MS DDK in a way that is usually not how you would declar...

by Thomas Faber

Woohoo, thanks! Questions/comments inline. On 2014-05-12 01:11, tkreuzer(a)svn.reactos.org wrote: > --- trunk/reactos/include/ddk/ntifs.h [iso-8859-1] (original) > +++ trunk/reactos/include/ddk/ntifs.h [iso-8859-1] Sun May 11 23:11:16 2014 > @@ -870,11 +870,11 @@ > (NTAPI *PRTL_FREE_STRING_ROUTINE)( > _In_ __drv_freesMem(Mem) _Post_invalid_ PVOID Buffer); > > -extern const PRTL_ALLOCATE_STRING_ROUTINE RtlAllocateStringRoutine; > -extern const PRTL_FREE_STRING_ROUTINE RtlFreeStringRoutine; > +extern NTKERNELAPI const PRTL_ALLOCATE_STRING_ROUTINE RtlAllocateStringRoutine; > +extern NTKERNELAPI const PRTL_FREE_STRING_ROUTINE RtlFreeStringRoutine; > > #if _WIN32_WINNT >= 0x0600 > -extern const PRTL_REALLOCATE_STRING_ROUTINE RtlReallocateStringRoutine; > +extern NTKERNELAPI const PRTL_REALLOCATE_STRING_ROUTINE RtlReallocateStringRoutine; > #endif > > _Function_class_(RTL_HEAP_COMMIT_ROUTINE) Do you have any idea what RtlAllocateStringRoutine and friends are? They don't seem to exist. (NDK defines them for user mode btw, without dllimport) > Modified: trunk/reactos/include/ddk/wdm.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/wdm.h?rev=6324… > ============================================================================== > --- trunk/reactos/include/ddk/wdm.h [iso-8859-1] (original) > +++ trunk/reactos/include/ddk/wdm.h [iso-8859-1] Sun May 11 23:11:16 2014 > @@ -82,10 +85,13 @@ > #endif > > /* For ReactOS */ > -#if !defined(_NTOSKRNL_) && !defined(_BLDR_) > +#if !defined(_NTOSKRNL_) && !defined(_BLDR_) && !defined(_NTSYSTEM_) > #define NTKERNELAPI DECLSPEC_IMPORT > #else > #define NTKERNELAPI > +#ifndef _NTSYSTEM_ > +#define _NTSYSTEM_ > +#endif > #endif > > #if defined(_X86_) && !defined(_NTHAL_) We should probably switch to using _NTSYSTEM_ instead of _NTOSKRNL_ at some point? > @@ -129,6 +135,29 @@ > #define ALLOC_DATA_PRAGMA 1 > #endif > > +#endif /* _MSC_VER */ > + > +/* These macros are used to create aliases for imported data. We need to do > + this to have declarations that are compatible with MS DDK */ > +#ifdef _M_IX86 > +#define __SYMBOL(_Name) "_"#_Name > +#define __IMPORTSYMBOL(_Name) "__imp__"#_Name > +#define __IMPORTNAME(_Name) _imp__##_Name > +#else > +#define __SYMBOL(_Name) #_Name > +#define __IMPORTSYMBOL(_Name) "__imp_"#_Name > +#define __IMPORTNAME(_Name) __imp_##_Name > +#endif > +#ifdef _MSC_VER > +#define __CREATE_NTOS_DATA_IMPORT_ALIAS(_Name) \ > + __pragma(comment(linker, "/alternatename:"__SYMBOL(_Name) "=" __IMPORTSYMBOL(_Name))) > +#else /* !_MSC_VER */ > +#ifndef __STRINGIFY > +#define __STRINGIFY(_exp) #_exp > +#endif > +#define _Pragma_redifine_extname(_Name, _Target) _Pragma(__STRINGIFY(redefine_extname _Name _Target)) > +#define __CREATE_NTOS_DATA_IMPORT_ALIAS(_Name) \ > + _Pragma_redifine_extname(_Name,__IMPORTNAME(_Name)) > #endif > > #if defined(_WIN64) s/redifine/redefine/ > --- trunk/reactos/ntoskrnl/kd64/kdapi.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/kd64/kdapi.c [iso-8859-1] Sun May 11 23:11:16 2014 > @@ -1903,9 +1903,7 @@ > > /* We are disabled now */ > KdDebuggerEnabled = FALSE; > -#undef KdDebuggerEnabled > SharedUserData->KdDebuggerEnabled = FALSE; > -#define KdDebuggerEnabled _KdDebuggerEnabled > } > } Should this not use KD_DEBUGGER_ENABLED? (same in kdinit.c)

11 years, 4 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [cwittich] 63225: [comctl32] Notify the parent on a return key press. fixes return key in device manager

by Hermès BÉLUSCA - MAÏTO

Hi Christoph ! Are you sure that before committing this fix in Wine code, you: 1- made a patch to wine's code, 2- sent it to them, and 3- checked that they merged too in their code base? Because otherwise your fix here might be lost in the next Wine code sync... Cheers, Hermès. -----Message d'origine----- Author: cwittich Date: Sun May 11 05:04:56 2014 New Revision: 63225 URL: http://svn.reactos.org/svn/reactos?rev=63225&view=rev Log: [comctl32] Notify the parent on a return key press. fixes return key in device manager Modified: trunk/reactos/dll/win32/comctl32/treeview.c Modified: trunk/reactos/dll/win32/comctl32/treeview.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/comctl32/treeview .c?rev=63225&r1=63224&r2=63225&view=diff ============================================================================ == --- trunk/reactos/dll/win32/comctl32/treeview.c [iso-8859-1] (original) +++ trunk/reactos/dll/win32/comctl32/treeview.c [iso-8859-1] Sun May 11 05:04:56 2014 @@ -5242,6 +5242,10 @@ newSelection = TREEVIEW_GetNextListItem(infoPtr, prevItem); break; + case VK_RETURN: + TREEVIEW_SendSimpleNotify(infoPtr, NM_RETURN); + break; + case VK_HOME: newSelection = infoPtr->root->firstChild; break;

11 years, 4 months

1
1
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 63202: [RPCRT4] Detect whether we are connecting to a pipe on the local machine and use the \\.\ prefix instead of the full machine name. This patch modifies ReactOS-specific code (that ...

by Timo Kreuzer

Am 09.05.2014 03:57, schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Fri May 9 01:57:43 2014 > New Revision: 63202 > > URL: http://svn.reactos.org/svn/reactos?rev=63202&view=rev > Log: > [RPCRT4] > Detect whether we are connecting to a pipe on the local machine and use the \\.\ prefix instead of the full machine name. > This patch modifies ReactOS-specific code (that was introduced by Eric in revision 53630) (Wine still supports only local pipes), so I also update our rpcrt4_ros.diff file accordingly, r63201 with respect to the latest Wine 1.7.17 rpcrt4 code. > Modified: trunk/reactos/dll/win32/rpcrt4/rpcrt4_ros.diff > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/rpcrt4/rpcrt4_ro… > ============================================================================== > [...] > > +diff -prudN .\wine\dlls\rpcrt4/msvc.S .\reactos\dll\win32\rpcrt4/msvc.S > +--- .\wine\dlls\rpcrt4/msvc.S 1970-01-01 01:00:00.000000000 +0100 > ++++ .\reactos\dll\win32\rpcrt4/msvc.S 2012-02-14 21:27:35.943001900 +0100 > +@@ -0,0 +1,146 @@ > > +diff -prudN .\wine\dlls\rpcrt4/precomp.h .\reactos\dll\win32\rpcrt4/precomp.h > +--- .\wine\dlls\rpcrt4/precomp.h 1970-01-01 01:00:00.000000000 +0100 > ++++ .\reactos\dll\win32\rpcrt4/precomp.h 2014-03-14 01:43:22.357516600 +0100 > > +diff -prudN .\wine\dlls\rpcrt4/unix_func.c .\reactos\dll\win32\rpcrt4/unix_func.c > +--- .\wine\dlls\rpcrt4/unix_func.c 1970-01-01 01:00:00.000000000 +0100 > ++++ .\reactos\dll\win32\rpcrt4/unix_func.c 2013-01-25 00:19:53.278052800 +0100 Why add these to the diff?

11 years, 4 months

2
1
0 0

r58367 - Fix a bug in StartupWindowThread

by Aleksey Bragin

Hi, http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msgina/gui.c?r1=… Is there a point in that DuplicateHandle call? "When SetThreadDesktop is called the system closes the desktop handle when needed so we have to create a new handle because this handle may still be in use by winlogon" Sorry, I re-read that comment a few times and still can't understand. I take it that SetThreadDesktop closes the old handle which was set before. And it may, for some reason, be used by winlogon. Shouldn't that be a place to fix, rather than the hack in r58367? And why is the SetThreadDesktop(OldDesk) is removed by this revision? Regards, Aleksey Bragin

11 years, 4 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [dquintana] 63044: [RSHELL] [SHELL32] * Move the IID_NULL_PPV_ARG macro to the shobj_undoc header, next to the (also ros-specific) IID_PPV_ARG macro, so that it can be used elsewhere. [SHELL32] * M...

by Thomas Faber

On 2014-04-29 13:14, dquintana(a)svn.reactos.org wrote: > [SHELL32] > * Make use of IID_NULL_PPV_ARG in all the calls to GetUIObjectOf, and fix one instance of mismatched riid/pointer. I don't see that mismatch. What am I missing? ;)

11 years, 4 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [tfaber] 63030: [FIND] - Avoid printf on a non-format string. Spotted by Víctor - Remove broken pseudo-TCHAR usage CORE-8112 #resolve

by Timo Kreuzer

Am 28.04.2014 10:06, schrieb tfaber(a)svn.reactos.org: > @@ -235,9 +235,9 @@ > } > else > { > - LoadString(GetModuleHandle(NULL), IDS_CANNOT_OPEN, (LPTSTR)lpMessage, 4096); > - CharToOem(lpMessage, lpMessage); > - fprintf (stderr, lpMessage, > + LoadString (GetModuleHandle (NULL), IDS_CANNOT_OPEN, szMessage, sizeof(szMessage) / sizeof(szMessage[0])); > + CharToOemA (szMessage, szMessage); > + fprintf (stderr, szMessage, > finddata.name); > } LoadString -> LoadStringA? Also, shouldn't we go unicode?

11 years, 4 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [tfaber] 63032: [NETCFGX] - Use correct parent key instead of an uninitialized handle in INetCfgComponentControl_fnApplyRegistryChanges CORE-8115 #resolve

by Thomas Faber

Uh, this is missing the "Patch by Víctor Martínez" part, sorry. On 2014-04-28 10:27, tfaber(a)svn.reactos.org wrote: > Author: tfaber > Date: Mon Apr 28 08:27:57 2014 > New Revision: 63032 > > URL: http://svn.reactos.org/svn/reactos?rev=63032&view=rev > Log: > [NETCFGX] > - Use correct parent key instead of an uninitialized handle in INetCfgComponentControl_fnApplyRegistryChanges > CORE-8115 #resolve > > Modified: > trunk/reactos/dll/win32/netcfgx/tcpipconf_notify.c > > Modified: trunk/reactos/dll/win32/netcfgx/tcpipconf_notify.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/netcfgx/tcpipcon… > ============================================================================== > --- trunk/reactos/dll/win32/netcfgx/tcpipconf_notify.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/netcfgx/tcpipconf_notify.c [iso-8859-1] Mon Apr 28 08:27:57 2014 > @@ -3141,7 +3141,7 @@ > //MessageBoxW(NULL, L"INetCfgComponentControl_fnApplyRegistryChanges", NULL, MB_OK); > > > - if (RegCreateKeyExW(hKey, L"SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters", 0, NULL, 0, KEY_WRITE, NULL, &hKey, NULL) == ERROR_SUCCESS) > + if (RegCreateKeyExW(HKEY_LOCAL_MACHINE, L"SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters", 0, NULL, 0, KEY_WRITE, NULL, &hKey, NULL) == ERROR_SUCCESS) > { > if (pCurrentConfig->pDNS) > { > >

11 years, 4 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [jimtabor] 63027: [Win32k] - Moved to new menu structures, synced in wine code and started first phase to server side. Resulting that more tests are running and failing less. Unplugged ntuser bad f...

by Thomas Faber

Jim, this introduced a new warning: win32ss/user/user32/windows/menu.c:1952:14: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] Thanks. On 2014-04-28 08:40, jimtabor(a)svn.reactos.org wrote: > Author: jimtabor > Date: Mon Apr 28 03:55:23 2014 > New Revision: 63027 > > URL: http://svn.reactos.org/svn/reactos?rev=63027&view=rev > Log: > [Win32k] > - Moved to new menu structures, synced in wine code and started first phase to server side. Resulting that more tests are running and failing less. Unplugged ntuser bad functions. > - See CORE-5605, CORE-7447, CORE-7967, CORE-8098 and CORE-8107 > > Modified: > trunk/reactos/win32ss/include/ntuser.h > trunk/reactos/win32ss/user/ntuser/accelerator.c > trunk/reactos/win32ss/user/ntuser/menu.c > trunk/reactos/win32ss/user/ntuser/menu.h > trunk/reactos/win32ss/user/ntuser/object.c > trunk/reactos/win32ss/user/ntuser/simplecall.c > trunk/reactos/win32ss/user/ntuser/userfuncs.h > trunk/reactos/win32ss/user/ntuser/window.c > trunk/reactos/win32ss/user/user32/windows/menu.c > > [This mail would be too long, it was shortened to contain the URLs only.] > > Modified: trunk/reactos/win32ss/include/ntuser.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/include/ntuser.h?r… > > Modified: trunk/reactos/win32ss/user/ntuser/accelerator.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/accele… > > Modified: trunk/reactos/win32ss/user/ntuser/menu.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/menu.c… > > Modified: trunk/reactos/win32ss/user/ntuser/menu.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/menu.h… > > Modified: trunk/reactos/win32ss/user/ntuser/object.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/object… > > Modified: trunk/reactos/win32ss/user/ntuser/simplecall.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/simple… > > Modified: trunk/reactos/win32ss/user/ntuser/userfuncs.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/userfu… > > Modified: trunk/reactos/win32ss/user/ntuser/window.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/window… > > Modified: trunk/reactos/win32ss/user/user32/windows/menu.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/user32/window… > >

11 years, 4 months

1
0
0 0

WebOS and ReactOS

by Alexander Rechitskiy

Let's bring up the webOS topic again. There is an interesting idea to port Nyx portability layer to Win32 and thus make Open webOS running in ReactOS/Windows. Nice user interface would be a benefit! http://www.openwebosproject.org/docs/architecture#.U1l8Uvl_vTo -- Best regards, Alexander Reachitskiy

11 years, 4 months

2
1
0 0

Status Meeting (April 2014)

by Aleksey Bragin

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 24th of April, 19:00 UTC. And this date is very close to now! IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. If someone still is not getting passwords sent before a meeting - please email Pierre before the meeting started to get one. Please send agenda proposals to me before the meeting, so that we can start with a proposed agenda. Regards, Aleksey Bragin

11 years, 4 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [akhaldi] 62898: [PSDK] * Add missing MAXLONGLONG definition.

by Timo Kreuzer

Am 22.04.2014 23:43, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Tue Apr 22 21:43:39 2014 > New Revision: 62898 > > URL: http://svn.reactos.org/svn/reactos?rev=62898&view=rev > Log: > [PSDK] > * Add missing MAXLONGLONG definition. > > Modified: > trunk/reactos/include/psdk/winnt.h > > Modified: trunk/reactos/include/psdk/winnt.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/winnt.h?rev=6… > ============================================================================== > --- trunk/reactos/include/psdk/winnt.h [iso-8859-1] (original) > +++ trunk/reactos/include/psdk/winnt.h [iso-8859-1] Tue Apr 22 21:43:39 2014 > @@ -1480,6 +1480,7 @@ > #define MAXBYTE 0xff > #define MAXWORD 0xffff > #define MAXDWORD 0xffffffff > +#define MAXLONGLONG (((LONGLONG)0x7fffffff << 32) | 0xffffffff) > #define PROCESSOR_INTEL_386 386 > #define PROCESSOR_INTEL_486 486 > #define PROCESSOR_INTEL_PENTIUM 586 > > > Why not use 0x7FFFFFFFFFFFFFFFLL ?

11 years, 4 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [aandrejevic] 62892: [NTVDM] Quit when ntvdm becomes the last process attached to the console.

by Thomas Faber

On 2014-04-22 22:46, aandrejevic(a)svn.reactos.org wrote: > --- branches/ntvdm/subsystems/ntvdm/ntvdm.c [iso-8859-1] (original) > +++ branches/ntvdm/subsystems/ntvdm/ntvdm.c [iso-8859-1] Tue Apr 22 20:46:50 2014 > @@ -196,6 +197,11 @@ > EmulatorInterrupt(0x23); > break; > } > + case CTRL_LAST_CLOSE_EVENT: > + { > + if (CommandThread) TerminateThread(CommandThread, 0); > + break; > + } > default: > { > /* Stop the VDM if the user logs out or closes the console */ Wasn't there an event to tell that thread to exit? Using TerminateThread like this feels icky.

11 years, 4 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 62779: [CDFS] Convert FCB pathname from simple buffer to unicode string. Please carefully review if I missed something

by Pierre Schweitzer

Hey! That's indeed a typo! Can someone commit a fix? I can't before Monday evening. Thanks! Pierre -------- Message original -------- Objet : Re: [ros-dev] [ros-diffs] [pschweitzer] 62779: [CDFS] Convert FCB pathname from simple buffer to unicode string. Please carefully review if I missed something De : Alexander Andrejevic <theflash(a)sdf.lonestar.org> À : ReactOS Development List <ros-dev(a)reactos.org> Cc : Hi, Correct me if I'm wrong, but the original version didn't modify the string length. Are you sure that should be "=" and not "=="? Regards, Alex On Sat, Apr 19, 2014 at 09:31:44AM +0200, Thomas Faber wrote: > On 2014-04-18 23:40, pschweitzer(a)svn.reactos.org wrote: > > --- trunk/reactos/drivers/filesystems/cdfs/fcb.c [iso-8859-1] (original) > > +++ trunk/reactos/drivers/filesystems/cdfs/fcb.c [iso-8859-1] Fri Apr 18 21:40:02 2014 > > @@ -129,7 +131,7 @@ > > BOOLEAN > > CdfsFCBIsRoot(PFCB Fcb) > > { > > - return(wcscmp(Fcb->PathName, L"\\") == 0); > > + return (Fcb->PathName.Length = sizeof(WCHAR) && Fcb->PathName.Buffer[0] == L'\\'); > > } > > == > > > > Generally I'm seeing a lot of manual work where > RtlInitEmptyUnicodeString and RtlCopyUnicodeString could be used. > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev -- Alexander Andrejevic <theflash(a)sdf.lonestar.org> SDF Public Access UNIX System - http://sdf.lonestar.org _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

11 years, 4 months

3
2
0 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 62779: [CDFS] Convert FCB pathname from simple buffer to unicode string. Please carefully review if I missed something

by Thomas Faber

On 2014-04-18 23:40, pschweitzer(a)svn.reactos.org wrote: > --- trunk/reactos/drivers/filesystems/cdfs/fcb.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/cdfs/fcb.c [iso-8859-1] Fri Apr 18 21:40:02 2014 > @@ -129,7 +131,7 @@ > BOOLEAN > CdfsFCBIsRoot(PFCB Fcb) > { > - return(wcscmp(Fcb->PathName, L"\\") == 0); > + return (Fcb->PathName.Length = sizeof(WCHAR) && Fcb->PathName.Buffer[0] == L'\\'); > } == Generally I'm seeing a lot of manual work where RtlInitEmptyUnicodeString and RtlCopyUnicodeString could be used.

11 years, 4 months

3
2
0 0

Re: [ros-dev] [ros-bugs] [jira] (ONLINE-446) "Prove you are a human" game is hidden by AdBlock

by Richard Campbell

I couldn't resist. As a publisher...maybe you shouldn't run ad block eh? :) On Thu, Apr 17, 2014 at 12:09 AM, Sergey Bugaev (JIRA) <noreply(a)reactos.org>wrote: > > [ > http://jira.reactos.org/browse/ONLINE-446?page=com.atlassian.jira.plugin.sy…] > > Sergey Bugaev resolved ONLINE-446. > ---------------------------------- > > Resolution: Cannot Reproduce > > > "Prove you are a human" game is hidden by AdBlock > > ------------------------------------------------- > > > > Key: ONLINE-446 > > URL: http://jira.reactos.org/browse/ONLINE-446 > > Project: ReactOS Online Service > > Issue Type: Improvement > > Reporter: Sergey Bugaev > > Assignee: Aleksey Bragin > > > > https://www.reactos.org/user/register (use incognito mode or just log > out to see the issue) > > There is a game to prove you are a human. > > However if you are using AdBlock ( > https://chrome.google.com/webstore/detail/adblock/gighmmpiobklfepjocnamgkkb…, > the most popular Chrome extension with more than 15 million users) the game > is not visible, so newcomer can't register. > > The error message is "You didn't pass the game", which is not very > informative in that case. > > Should be something like "You didn't pass the game, try disabling > AdBlock to see it". The best solution would be making the game visible > anyway. > > Tested in Google Chrome > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators > For more information on JIRA, see: http://www.atlassian.com/software/jira > > _______________________________________________ > Ros-bugs mailing list > Ros-bugs(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-bugs >

11 years, 5 months

2
1
0 0

Heartbleed issue on the ReactOS infrastructure

by Pierre Schweitzer

Dear all, In case you don't use SSL/TLS on our infrastructure (web sites - drupal, jira, fisheye), skip reading (and reconsider your choices about such non-usage). As you may (should?) have heard recently, OpenSSL has suffered a critical security vulnerability (CVE-2014-0160), known as Heartbleed Bug (http://heartbleed.com/). Most of our services were using an affected release of OpenSSL, with heartbeat feature activated. Be it, mails services, web services (Drupal, Jira). We reacted quickly passed the public announcement, and the availability of the fix to apply it on our infrastructure to limit the risks. Anyway, this might have been enough (actually, the issue has been here for two years!) to allow potentials attackers to, for instance, steal our SSL private keys. So, we took the decision to renew all our certificates and private keys to guarantee safe infrastructure usage. Due to the nature of the security issue, we don't know what may have been compromised in the infrastructure and in the user database. Hence our drastic measures. What does it mean for you? It means that your account information (username + password) might have been compromised, and your account itself could have been compromised (cookie stealth with the attack). We highly recommend you to change your passwords and check that everything is fine on your account. I shall remind you that password change can take up to 6h to propagate to Fisheye & Jira. As a side note, we enabled a while ago Perfect Forward Secrecy on our infrastructure that should ensure that even if our private keys leaked, your past communications (so, login on the infrastructure, for instance) can't be deciphered. Unless your session ticket leaked as well... We are really sorry for the caused inconvenience. I'm available by email or on IRC to answer your questions and clear your doubts. With my best regards, -- Pierre Schweitzer<pierre at reactos.org> System Administrator ReactOS Foundation

11 years, 5 months

1
0
0 0

Short announce: My Serial port-on-MMIO implementation works - allowing debug logging on laptops

by Minas Abrahamyan

Hi all, With this few words I would like to share the joyous event of MMIO-based serial port implementation has finally worked for me. This is the equivalent of earlycon serial port implementation in Linux with some extension (so now it is even better then Linux one) Some work yet is needed to be done to transform the work into the normal patch, but the good news is it is working, and still doesn't require PNPmanager for work, i.e. it starts very early in kernel and writes kernel log messages. I use ExpressCard 34 extension board Serial RS232 port, on laptop, but think it will work fro PC Cards too (former name PCMCIA). ==Importance: Touching the hardware== For the more developers we need more working PC models ( Real Hardware) Almost all modern PCs are laptops with PCIe bus (the rest are desktops) (but few of them able to boot the ReactOS) Modern serial ports are recommended to use /often use MMIO-based data transfer instead of former I/O ports. So now possibility appears to debug these new computers and force the ReactOS to work on this important part of new PCs. Thanks for attention -Minas Abrahamyan PS Curious note: for catching the debug logs I use the (small and cheap) soap box-sized microcontroller board with LCD (ready-unit), and I call it "ReactOS debug logger" appliance. It doesn't take space and doesn't produce any noise

11 years, 5 months

3
4
0 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 62675: [CHARMAP] Use rather wcsncpy(). A bit less safe, but at least, data are copied till possible

by Timo Kreuzer

I don't really see the reason here. Whether using the secure function or not is is a question of whether we need null-termination or not. If we need it the secure function will do the right thing. If we do not need null-termination the non-secure function does the right thing and the secure function would not add any security, but simply do the wrong thing. MSDN says about the lfFaceName member of the LOGFONT structure "A null-terminated string that specifies the typeface name of the font. " So we want it to be null-terminated and adding one more character does not add anything useful, but will result in a broken structure. Another difference is that the non-secure function pads the destination array with nulls, the secure function does - afaik - not. If that is the reason, I'd prefer zeroing it out before copying the string. Am 06.04.2014 22:20, schrieb pschweitzer(a)svn.reactos.org: > Author: pschweitzer > Date: Sun Apr 6 20:20:39 2014 > New Revision: 62675 > > URL: http://svn.reactos.org/svn/reactos?rev=62675&view=rev > Log: > [CHARMAP] > Use rather wcsncpy(). A bit less safe, but at least, data are copied till possible > > Modified: > trunk/reactos/base/applications/charmap/lrgcell.c > trunk/reactos/base/applications/charmap/map.c > > Modified: trunk/reactos/base/applications/charmap/lrgcell.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/charmap/… > ============================================================================== > --- trunk/reactos/base/applications/charmap/lrgcell.c [iso-8859-1] (original) > +++ trunk/reactos/base/applications/charmap/lrgcell.c [iso-8859-1] Sun Apr 6 20:20:39 2014 > @@ -48,9 +48,9 @@ > hdc); > > lf.lfCharSet = DEFAULT_CHARSET; > - wcscpy_s(lf.lfFaceName, > - sizeof(lf.lfFaceName) / sizeof(lf.lfFaceName[0]), > - lpFontName); > + wcsncpy(lf.lfFaceName, > + lpFontName, > + sizeof(lf.lfFaceName) / sizeof(lf.lfFaceName[0])); > > hFont = CreateFontIndirectW(&lf); > > > Modified: trunk/reactos/base/applications/charmap/map.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/charmap/… > ============================================================================== > --- trunk/reactos/base/applications/charmap/map.c [iso-8859-1] (original) > +++ trunk/reactos/base/applications/charmap/map.c [iso-8859-1] Sun Apr 6 20:20:39 2014 > @@ -228,9 +228,9 @@ > ReleaseDC(infoPtr->hMapWnd, hdc); > > infoPtr->CurrentFont.lfCharSet = DEFAULT_CHARSET; > - wcscpy_s(infoPtr->CurrentFont.lfFaceName, > - sizeof(infoPtr->CurrentFont.lfFaceName) / sizeof(infoPtr->CurrentFont.lfFaceName[0]), > - lpFontName); > + wcsncpy(infoPtr->CurrentFont.lfFaceName, > + lpFontName, > + sizeof(infoPtr->CurrentFont.lfFaceName) / sizeof(infoPtr->CurrentFont.lfFaceName[0])); > > infoPtr->hFont = CreateFontIndirectW(&infoPtr->CurrentFont); > > > >

11 years, 5 months

3
3
0 0

Re: [ros-dev] [ros-diffs] [khornicek] 62665: [MAIN] - fix a copypasta - fix a possible buffer overrun (x5) - fix a negative array index access

by Thomas Faber

You guys should consider replacing that stuff with strsafe functions while you're at it ;) On 2014-04-06 18:45, khornicek(a)svn.reactos.org wrote: > Author: khornicek > Date: Sun Apr 6 16:45:21 2014 > New Revision: 62665 > > URL: http://svn.reactos.org/svn/reactos?rev=62665&view=rev > Log: > [MAIN] > - fix a copypasta > - fix a possible buffer overrun (x5) > - fix a negative array index access > > Modified: > trunk/reactos/dll/cpl/main/mouse.c > > Modified: trunk/reactos/dll/cpl/main/mouse.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/cpl/main/mouse.c?rev=6… > ============================================================================== > --- trunk/reactos/dll/cpl/main/mouse.c [iso-8859-1] (original) > +++ trunk/reactos/dll/cpl/main/mouse.c [iso-8859-1] Sun Apr 6 16:45:21 2014 > @@ -499,7 +499,7 @@ > /* Remove quotation marks */ > if (szTempData[0] == _T('"')) > { > - lpStart = szValueData + 1; > + lpStart = szTempData + 1; > szTempData[_tcslen(szTempData) - 1] = 0; > } > else > @@ -1022,9 +1022,9 @@ > static VOID > LoadInitialCursorScheme(HWND hwndDlg) > { > - TCHAR szSchemeName[256]; > - TCHAR szSystemScheme[256]; > - TCHAR szCursorPath[256]; > + TCHAR szSchemeName[MAX_PATH]; > + TCHAR szSystemScheme[MAX_PATH]; > + TCHAR szCursorPath[MAX_PATH]; > HKEY hCursorKey; > LONG lError; > DWORD dwDataSize; > @@ -1057,7 +1057,7 @@ > > if (dwSchemeSource != 0) > { > - dwDataSize = 256 * sizeof(TCHAR); > + dwDataSize = MAX_PATH * sizeof(TCHAR); > lError = RegQueryValueEx(hCursorKey, > NULL, > NULL, > @@ -1101,8 +1101,8 @@ > else if (dwSchemeSource == 2) > { > LoadString(hApplet, IDS_SYSTEM_SCHEME, szSystemScheme, MAX_PATH); > - _tcscat(szSchemeName, _T(" ")); > - _tcscat(szSchemeName, szSystemScheme); > + _tcsncat(szSchemeName, _T(" "), MAX_PATH - _tcslen(szSchemeName)); > + _tcsncat(szSchemeName, szSystemScheme, MAX_PATH - _tcslen(szSchemeName)); > } > > /* Search and select the curent scheme name from the scheme list */ > @@ -1276,6 +1276,10 @@ > { > case LBN_SELCHANGE: > nSel = SendMessage((HWND)lParam, LB_GETCURSEL, 0, 0); > + > + if(nSel == LB_ERR) > + break; > + > SendDlgItemMessage(hwndDlg, IDC_IMAGE_CURRENT_CURSOR, STM_SETIMAGE, IMAGE_CURSOR, > (LPARAM)g_CursorData[nSel].hCursor); > EnableWindow(GetDlgItem(hwndDlg,IDC_BUTTON_USE_DEFAULT_CURSOR), > >

11 years, 5 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 62662: [NTDLL_APITEST]: Add braces and remove an unneeded trace.

by Thomas Faber

This will make any failure messages in the loop useless, since you won't know which test they're about. Just because the tests are succeeding now doesn't mean they always will. On 2014-04-06 17:51, hbelusca(a)svn.reactos.org wrote: > @@ -188,7 +190,6 @@ > > for (i = 0; i < TestCount; i++) > { > - trace("i = %d\n", i); > switch (TestCases[i].PrefixType) > { > case PrefixNone: > >

11 years, 5 months

2
2
0 0

Re: [ros-dev] [ros-diffs] [dgorbachev] 62598: [BUGCODES] - Add an error message for Proprietary Software Execution Prevention feature supported by recent CPUs. - TODO: Implement this feature in the kernel.‏

by Pierre Schweitzer

Nice one :-). I thought you'd commit your ReactOS 1.0 patch today! Beware though, you're sitting BUGCODE_NDIS_DRIVER. Regards, -- Pierre Schweitzer <pierre(a)reactos.org> System Administrator ReactOS Foundation

11 years, 5 months

4
3
0 0

Re: [ros-dev] [ros-builds] Linux_AMD64_2 VMWPlayer-Test: build failed

by Pierre Schweitzer

Working on DB server atm (hence the fails). Results will be properly submitted later on. Ignore failed shell errors for the next hour. Sorry about that. On 04/01/2014 11:24 AM, buildbot(a)reactos.org wrote: > The Buildbot has detected a failed build on builder Linux_AMD64_2 VMWPlayer-Test while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Linux_AMD64_2%20VMWPlayer-Test/builds/3636 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_2 > > Build Reason: Triggerable(Linux_AMD64_1 KVM-Test Trigger) > Build Source Stamp: 62598 > Blamelist: > > BUILD FAILED: failed shell > > sincerely, > -The Buildbot > > > > -- Pierre Schweitzer <pierre(a)reactos.org> System Administrator ReactOS Foundation

11 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev