Ros-dev

ros-dev@reactos.org

5789 discussions

Re: [ros-dev] [ros-diffs] [hbelusca] 62562: [EXT2] try_return() == try_return(S) with nothing in S . The code sometimes use it. Shut up MSVC warning C4003: not enough actual parameters for macro 'try_return'.

by Thomas Faber

That's illegal, macros can't be overloaded. drivers/filesystems/ext2/inc/ext2fsd.h:64:0: warning: "try_return" redefined [enabled by default] You could try #define try_return(...) { __VA_ARGS__; goto try_exit; } If that doesn't do it, it might simply need a separate macro (I'm not sure to what extent this is third party code though) (also if these were the last instances of that -- and I think so --, we might want to make 4003 an error) On 2014-03-24 23:20, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Mon Mar 24 22:20:52 2014 > New Revision: 62562 > > URL: http://svn.reactos.org/svn/reactos?rev=62562&view=rev > Log: > [EXT2] > try_return() == try_return(S) with nothing in S . The code sometimes use it. > Shut up MSVC warning C4003: not enough actual parameters for macro 'try_return'. > > Modified: > trunk/reactos/drivers/filesystems/ext2/inc/ext2fsd.h > > Modified: trunk/reactos/drivers/filesystems/ext2/inc/ext2fsd.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/ext2/i… > ============================================================================== > --- trunk/reactos/drivers/filesystems/ext2/inc/ext2fsd.h [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/ext2/inc/ext2fsd.h [iso-8859-1] Mon Mar 24 22:20:52 2014 > @@ -60,6 +60,7 @@ > extern Ext2Data Ext2GlobalData; > > // try-finally simulation > +#define try_return() { goto try_exit; } > #define try_return(S) { S; goto try_exit; } > #define try_return1(S) { S; goto try_exit1; } > #define try_return2(S) { S; goto try_exit2; } > >

11 years, 1 month

Installing and running ReactOS on modern hardware

by Thomas Mueller

I would like to build and install ReactOS from source but may be strapped for where to install it. I have USB sticks, 3 TB SATA hard drives, and 3 TB USB 3.0 hard drive. Hard drives are GPT-partitioned, which ReactOS apparently doesn't support. I have some old IDE hard drives which I access with USB 2.0 enclosure: 1271 MB and 40 GB. I also have an old 341 MB IDE hard drive that I can't read through USB 2.0 enclosure. I could compile from Linux or FreeBSD with ROSBE, could do further builds that way or with Wine and MinGW under Linux or FreeBSD. I don't want to do heavy compiling on USB stick if I can avoid it. I believe the only file system ReactOS currently supports is FAT16 or FAT32, which limits possible partition size compared to NTFS or Linux or BSD file systems. Can I install to USB stick, 4GB or 8 GB, and are there any other possibilities with my hardware? Tom

11 years, 1 month

What's happening to the build bots??

by Hermès BÉLUSCA - MAÏTO

Hi all! Since some time now, most of our build bots are unavailable (see http://build.reactos.org/builders , the ones maintained by Olaf). What is happening to them? I sent him a mail but no answer so far I have received. We *need* those bots! , and especially the patch-bot that I am waiting for, because I have two big patches in my local wc that need to be tested and I cannot proceed further for now (and surely other have too, according to some recent Jira reports). Please fix them asap. if possible :D Cheers, Hermès

11 years, 1 month

Re: [ros-dev] [ros-diffs] [tkreuzer] 62480: [PSDK] winternl.h: Fix RtlLookupAtomInAtomTable prototype (should be sent to wine? not sure)

by Thomas Faber

This is intentional, their RTL_ATOM_TABLE is already a pointer: /* Wine doesn't implement atom table as NT does: * - in NT, atom tables are user space tables, which ntdll directly accesses * - on Wine, (even local) atom tables are wineserver objects, hence a HANDLE */ typedef struct atom_table *RTL_ATOM_TABLE, **PRTL_ATOM_TABLE; So that would need to be changed consistently. (also, winternl.h should be used by Wine code only, so shouldn't affect us -- since we have NDK to use instead) On 2014-03-11 23:48, tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Tue Mar 11 22:48:04 2014 > New Revision: 62480 > > URL: http://svn.reactos.org/svn/reactos?rev=62480&view=rev > Log: > [PSDK] > winternl.h: Fix RtlLookupAtomInAtomTable prototype (should be sent to wine? not sure) > > Modified: > trunk/reactos/include/psdk/winternl.h > > Modified: trunk/reactos/include/psdk/winternl.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/winternl.h?re… > ============================================================================== > --- trunk/reactos/include/psdk/winternl.h [iso-8859-1] (original) > +++ trunk/reactos/include/psdk/winternl.h [iso-8859-1] Tue Mar 11 22:48:04 2014 > @@ -632,7 +632,7 @@ > FileFsMaximumInformation > } FS_INFORMATION_CLASS, *PFS_INFORMATION_CLASS; > > -typedef enum _KEY_INFORMATION_CLASS { > +typedef enum _KEY_INFORMATION_CLASS { > KeyBasicInformation = 0, > KeyNodeInformation = 1, > KeyFullInformation = 2, > @@ -2244,7 +2244,7 @@ > DWORD WINAPI RtlLengthSid(PSID); > NTSTATUS WINAPI RtlLocalTimeToSystemTime(const LARGE_INTEGER*,PLARGE_INTEGER); > BOOLEAN WINAPI RtlLockHeap(HANDLE); > -NTSTATUS WINAPI RtlLookupAtomInAtomTable(RTL_ATOM_TABLE,const WCHAR*,RTL_ATOM*); > +NTSTATUS WINAPI RtlLookupAtomInAtomTable(RTL_ATOM_TABLE*,const WCHAR*,RTL_ATOM*); > > NTSTATUS WINAPI RtlMakeSelfRelativeSD(PSECURITY_DESCRIPTOR,PSECURITY_DESCRIPTOR,LPDWORD); > void WINAPI RtlMapGenericMask(PACCESS_MASK,const GENERIC_MAPPING*); > >

11 years, 1 month

Thoughts on Kickstarter

by Ólafur Arason

Hi, I've been following the project for years and I've even used explorer implementation on Windows. I also went to the Montreal event. I'm a linux user so I won't be a full time user any time soon. What I think would make a really good Kickstarter, having watched the Thorium Core progress: Developers Delight: What ReactOS or Thorium D has going for it is fully debugable and fundamental understanding of how Windows works. Microsoft has Visual Studio Online but it's pretty bad, at least at the moment it's a mess to set up. Having a way to run your MinGW-w64 projects, possible compile them. Having support for Clang msvc implementation. And last and not the least is the Visual Studio, which of course is the hardest. Even without that it's going to be really solid. An extra plus is being able to make Windows Embedded development stack running, because Trimble are really tied to that. Also Delphi and what ever other development you can think of. Having git support with CI type workflow is going to be great and with kernel level debug reports what could be better. The MingGW-w64 is going to great for all the open source software developers that need something to develop windows software without touching windows. You should talk with OpenShot they were having problems with that kind of development. This is going to be a double benefit for you guys, not only will it provide you with information about what people are using and what bugs are in your system but also provide a lot of foss software on your platform. Embedded dreams: Now that XP is through people need an embedded version, Windows Embedded isn't it, because it has a really weird api. Vista isn't really there or 7 so, where is your chance. Banks are paying Microsoft to extend XP for their ATMs but not every one can afford it. Enter Thorium E, for all those kiosks and POS. You have greater control so you can build a kit for Embedded user where they decide what's going to be included and what comes up, like not having a screen saver, virus software, IE, only allowing one or two exe files to run and only certain dlls. This would also be perfect to make single use virtual images with only one program running. If you need any help with making the video or with the campaign I would love to help. Regards, Olaf

11 years, 1 month

[CORE-7969] A week later

by Minas Abrahamyan

Hi developers, Passed a week after I provided a ready for review and apply patch, a simplest solution for simplest bug. Could anyone review, test, and apply it? https://jira.reactos.org/browse/CORE-7969 Thanks

11 years, 1 month

ReactOS needs to be self-hostable!

by Hermès BÉLUSCA - MAÏTO

Hi all ! ReactOS severely needs to be self-hostable for many reasons, one of it because it could allow people who only have Linux to be able to program / debug ReactOS with Windows tools (e.g. we have some people here and there complaining that they cannot use powerful debugging programs for debugging ReactOS (e.g. WinDbg and so on with MSVC builds of ReactOS) and therefore restrain themselves in using the Goode Olde GCC + DPRINT method, because they are running only on Linux). Something more personal is that I really want to program ReactOS on itself (in a VM) when it becomes self-hostable. But there are *only* few steps remaining before ReactOS can really be in such situation !! Ive already tested RosBE on it and I was able to download and configure a build. But there *are still* problems. Here is my setup on a VM: main HDD of letter drive C: with ReactOS, second HDD of letter drive D: with ROS source code in D:\rossrc, third HDD of letter drive E: with build output files in E:\rosbuild . After having successfully configured a build in the usual way (E:\rosbuild> D:\rossrc\configure.cmd), I first tried to compile the host-tools (cd host-tools && ninja). The first thing that Ive noticed is that doing so retriggered a configure, then the compilation as wanted. I retried again, and again it reconfigured the build before actually rebuilding the host-tools. The same phenomenon appears then when trying to build ReactOS proper. After analyzing produced files by the configuration step and comparing with a clean build on windows 2k3, it became clear that few files were missing, because obviously not generated: E:\rosbuild\host-tools\CMakeFiles\2.8.10.2-ReactOS\CMakeCCompiler.cmake and CMakeCXXCompiler.cmake . The other .cmake files that should also be present here (CMakeRCCompiler.cmake and CMakeSystem.cmake) as well as two .bin files and two subdirectories where present (and contain the same things). I was suggesting it might be a problem with the command-line interpreter, so I changed our cmd.exe with the one of windows 2000 (not win2k3, because the latter makes extra calls to some security APIs of advapi32 not implemented on ReactOS before running .bat / .cmd files, and it fails), but nothing changed, the files were not still present. After having enabled extra debug output of cmake (that is called when configuring a build) by adding the flags --debug-output --trace (without quotes) in the cmake calls in configure.cmd (and after redirecting console stdout + stderr to a file when retrigerring a clean configuration), doing that on ReactOS *and* on win2k3 for comparison purposes, I saw that, at some point, some cmake flags concerning compiler recognition (à la: CMAKE_GCC_EXISTS for example) werent set to TRUE or FALSE, but were kept empty. So Im wondering whether it is actually some issue, either concerning our C runtime library (e.g. some called sprintf-like function fails or whatever) is buggy and something fails, OR, something file-system related. Concerning file-system, you know that we have LOTS of kernel32:file winetests failing, about problems for deleting files, recreating (or just creating) them, and so on Maybe for some reason cmake fails to create those CMake(C/CXX)Compiler.cmake files for the same reason one of the kernel32:file tests fail ? I dont know, this previous point being speculative since I didnt test anything regarding that. Therefore it would be very nice *to see you all* trying to uncover where this bug comes from so that you can *finally* declare ReactOS self-hostable before, maybe, the next release !! Cheers, Hermès

11 years, 1 month

Re: [ros-dev] [ros-diffs] [fireball] 62477: [NTOS] - Remove unneeded macro by David Welch in 2002 and me in 2003.

by Timo Kreuzer

Good sart, but I'm going to outperform this cleanup approach a bit... ;-) Am 11.03.2014 19:46, schrieb fireball(a)svn.reactos.org: > Author: fireball > Date: Tue Mar 11 18:46:32 2014 > New Revision: 62477 > > URL: http://svn.reactos.org/svn/reactos?rev=62477&view=rev > Log: > [NTOS] > - Remove unneeded macro by David Welch in 2002 and me in 2003. > > Modified: > trunk/reactos/ntoskrnl/mm/i386/page.c > > Modified: trunk/reactos/ntoskrnl/mm/i386/page.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/i386/page.c?re… > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/i386/page.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/i386/page.c [iso-8859-1] Tue Mar 11 18:46:32 2014 > @@ -40,22 +40,10 @@ > #define PA_ACCESSED (1 << PA_BIT_ACCESSED) > #define PA_GLOBAL (1 << PA_BIT_GLOBAL) > > -#define HYPERSPACE (0xc0400000) > -#define IS_HYPERSPACE(v) (((ULONG)(v) >= HYPERSPACE && (ULONG)(v) < HYPERSPACE + 0x400000)) > +#define IS_HYPERSPACE(v) (((ULONG)(v) >= HYPER_SPACE && (ULONG)(v) <= HYPER_SPACE_END)) > > #define PTE_TO_PFN(X) ((X) >> PAGE_SHIFT) > #define PFN_TO_PTE(X) ((X) << PAGE_SHIFT) > - > -#if defined(__GNUC__) > -#define PTE_TO_PAGE(X) ((LARGE_INTEGER)(LONGLONG)(PAGE_MASK(X))) > -#else > -__inline LARGE_INTEGER PTE_TO_PAGE(ULONG npage) > -{ > - LARGE_INTEGER dummy; > - dummy.QuadPart = (LONGLONG)(PAGE_MASK(npage)); > - return dummy; > -} > -#endif > > const > ULONG > > >

11 years, 1 month

Valve has publushed Direct3D -> OpenGL translation layer

by Alexander Rechitskiy

Valve has publushed Direct3D -> OpenGL translation layer with BSD like license https://github.com/ValveSoftware/ToGL Taken directly from the DOTA2 source tree; supports: Limited subset of Direct3D 9.0c Bytecode-level HLSL -> GLSL translator Some SM3 support: Multiple Render Targets, no Vertex Texture Fetch This most likely won't build by itself and is provided as-is and completely unsupported. Feel free to use it for your reference, incorporate it into your projects or send us modifications. Be wary that some parts are hardcoded to match Source Engine behavior; see CentroidMaskFromName() and ShadowDepthSamplerMaskFromName() in dxabstract.cpp. Please refer to the LICENSE file for more information. -- Best regards Alexander Rechitskiy

11 years, 1 month

Re: [ros-dev] [ros-diffs] [pschweitzer] 62442: [NTOSKRNL] - Implement FsRtlNotifyFilterReportChange - Implement FsRtlNotifyUpdateBuffer - Implement FsRtlCancelNotify - Implement FsRtlNotifyGetLastPartOffset - Fix implementa...

by Timo Kreuzer

See inline... Am 07.03.2014 20:33, schrieb pschweitzer(a)svn.reactos.org: > [...] > + /* Update user buffer with the change that occured > + * First copy parent name if any > + * Then copy target name, there's always one > + * And finally, copy stream name if any > + * If these names aren't unicode, then convert first > + */ > + _SEH2_TRY > + { > + OutputBuffer->NextEntryOffset = 0; > + OutputBuffer->Action = Action; > + OutputBuffer->FileNameLength = DataLength - sizeof(FILE_NOTIFY_INFORMATION); > + if (IsUnicode) > + { > + if (ParentName->Length) > + { > + RtlCopyMemory(OutputBuffer->FileName, ParentName->Buffer, ParentName->Length); > + OutputBuffer->FileName[ParentName->Length / sizeof(WCHAR)] = L'\\'; > + AlreadyWritten = ParentName->Length + sizeof(WCHAR); > + } > + RtlCopyMemory(OutputBuffer->FileName + AlreadyWritten, TargetName->Buffer, TargetName->Length); OutputBuffer->FileName is a WCHAR array, AlreadyWritten is a count of bytes, the pointer arithmetic is wrong here. > + if (StreamName) > + { > + AlreadyWritten += TargetName->Length; > + OutputBuffer->FileName[AlreadyWritten / sizeof(WCHAR)] = L':'; > + RtlCopyMemory(OutputBuffer->FileName + AlreadyWritten + sizeof(WCHAR), > + StreamName->Buffer, StreamName->Length); see above > + } > + } > + else > + { > + if (!ParentName->Length) > + { > + ASSERT(StreamName); > + RtlCopyMemory(OutputBuffer->FileName, StreamName->Buffer, StreamName->Length); > + } > + else > + { > + RtlOemToUnicodeN(OutputBuffer->FileName, OutputBuffer->FileNameLength, > + &ResultSize, ParentName->Buffer, > + ParentName->Length); > + OutputBuffer->FileName[ResultSize / sizeof(WCHAR)] = L'\\'; > + AlreadyWritten = ResultSize + sizeof(WCHAR); > + > + RtlOemToUnicodeN(OutputBuffer->FileName + AlreadyWritten, > + OutputBuffer->FileNameLength, &ResultSize, > + TargetName->Buffer, TargetName->Length); see above > + > + if (StreamName) > + { > + AlreadyWritten += ResultSize; > + OutputBuffer->FileName[AlreadyWritten / sizeof(WCHAR)] = L':'; > + RtlOemToUnicodeN(OutputBuffer->FileName + AlreadyWritten + sizeof(WCHAR), > + OutputBuffer->FileNameLength, &ResultSize, > + StreamName->Buffer, StreamName->Length); see above > [...] > + > + /* Look for target name & construct it, if required */ > + if (TargetName.Buffer) > + { > + TargetNameLength = TargetName.Length; The TargetNameLength vatiable is completely redundant > [...] > + > + /* Get the position where we can put our data (aligned!) */ > + AlignedDataLength = ROUND_UP(NotifyChange->DataLength, sizeof(ULONG)); > + /* If it's higher than buffer length, then, bail out without outputing */ > + if (DataLength > NumberOfBytes || AlignedDataLength + DataLength > NumberOfBytes) > + { > + NotifyChange->Flags |= NOTIFY_IMMEDIATELY; > + } > + else > + { > + OutputBuffer = 0; > + FileNotifyInfo = 0; Use NULL

11 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev