Ros-dev

ros-dev@reactos.org

5790 discussions

Re: [ros-diffs] [sedwards] 19673: more crt, crtdll and msvcrt cleanup

by Thomas Weidenmueller

sedwards(a)svn.reactos.com wrote: > more crt, crtdll and msvcrt cleanup > +#include "precomp.h" That doesn't work, it should be <precomp.h>.... - Thomas

20 years

Re: [ros-svn] [ion] 19693: - Remove KTSS_NOIOMP from NDK.

by Alex Ionescu

ion(a)svn.reactos.com wrote: >- Remove KTSS_NOIOMP from NDK. >- Fix KTSS definition. >- Fix KTRAP_FRAME definition. >- Fix RTL_PROCESS_BACKTRACE_INFORMATION and RTL_PROCESS_BACKTRACES definitions. >- Fix/rename RUNDOWN_DESCRIPTOR definition. >- Rename PPF_ definitions to RTL_USER_PROCESS_PARAMETERS_ >- Setup a global _REACTOS_ define when code is compiled. >- #ifdef out the multiboot flags from the NDK so they'll only be available for ReactOS. Dirty 'hack' until we stop using them. >- Update NDK Fixme list, since all major bugs are fixed now. > > > > Hi, Sorry, this breaks compiling. I think there is a bug in compilation units. I did make ntoskrnl_clean about 3 times, and even a complete "make depends -j2" and it compiled the whole tree fine. Then I started doing other changes, and I started getting build failures. Best regards, Alex Ionescu

20 years

Do it right first time ??

by Biera Gaino

It seems to me that is always best to do it right first time. Then it is easier to get quality, Well anyway it is my opinion. Like the Japanese car manufacturers discovered first, that is always best to track down and solve problems in early stage, than later...... Bierá L. gaino

20 years

Re: [ros-diffs] [ion] 19666: - Add DDK alignment macros and move/rename the ones in the NDK for user-mode only (since kernel-mode should use the DDK ones).

by Hartmut Birr

ion(a)svn.reactos.com wrote: > - Add DDK alignment macros and move/rename the ones in the NDK for user-mode only (since kernel-mode should use the DDK ones). > - Fix helper.h's alignment macros to protect properly and also use a faster implementation. > - Update NDK readme. > Modified: trunk/reactos/include/ndk/lpctypes.h > > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/include/ndk/lpctypes.h* > --- trunk/reactos/include/ndk/lpctypes.h 2005-11-26 23:26:04 UTC (rev 19665) > +++ trunk/reactos/include/ndk/lpctypes.h 2005-11-27 02:55:13 UTC (rev 19666) > @@ -234,9 +234,9 @@ > // Maximum total Kernel-Mode LPC Message Structure Size > // > #define LPCP_MAX_MESSAGE_SIZE \ > > - ROUND_UP(PORT_MAXIMUM_MESSAGE_LENGTH + \ > > + ALIGN_UP(PORT_MAXIMUM_MESSAGE_LENGTH + \ > > sizeof(LPCP_MESSAGE) + \ > > - sizeof(LPCP_CONNECTION_MESSAGE), 16) > > + sizeof(LPCP_CONNECTION_MESSAGE), sizeof(ULONGLONG) * 2) > > > // > // Maximum actual LPC Message Length > > ------------------------------------------------------------------------ This or the definition of ALIGN_UP is wrong. ALIGN_UP needs a type as second parameter. Now the value of LPCP_MAX_MESSAGE_SIZE, LPC_MAX_MESSAGE_LENGTH and LPC_MAX_DATA_LENGTH are changed. ReactOS won't boot because csrss uses hard coded values in CsrpCreateListenPort. - Hartmut

20 years

Re: [ros-dev] [Vote] Top-level source header

by Brandon Turner

Only developers can vote. Brandon Alex Buell wrote: > On Sun, 27 Nov 2005, Casper Hornstrup wrote: > >> http://www.reactos.org/forum/viewtopic.php?p=10398#10398 > > > Since I cannot vote (even though I've signed up), I'll stand up and > say I'd vote for option B if I could. >

20 years

Re: [ros-diffs] [turner] 19669: Don't hardcode user to .DEFAULT when reading registry

by Thomas Weidenmueller

turner(a)svn.reactos.com wrote: > Don't hardcode user to .DEFAULT when reading registry > > Modified: trunk/reactos/subsys/win32k/ntuser/misc.c > + NtClose(CurrentUserKey); This needs to be ZwClose - Thomas

20 years

Debian win32 port, file system, installer, ELF

by Drew Scott Daniels

Hi, For background in the Debian win32 port see the mailing list archives [1]. Basically, the only reason the port is allowed by Debian is that it could run on ReactOS or wine which are both DFSG [2] compliant. Microsoft Windows, OS/2... aren't DFSG compliant. I've read [3] that the Debian win32 ports "failed because most unix software made unforgivable presumptions about file system semantics; mainly that you could delete files that were in-use, and rename open files on top of other open files, etc." Is this something that could be resolved? I'd imagine the Installable File System (IFS) driver would need to be modified to remember open files, or perhaps something could intercept calls to an IFS driver? I think this is what some virus scanners do, and what clamav is missing. Porting Debian to ReactOS would give ReactOS a huge number of packages. The BSD ports collection method or gentoo's build systems may be useful too. All three would probably mean porting some base software though. Any comments about porting the base of another OS to ros? Packages like perl, bash, gcc, glibc seem to have native MS Windows ports. http://packages.debian.org/stable/base/ lists all the various packages in Debian's base (note some are specific to various ports, and there are some semi-duplicated packages). Another advantage of a Debian win32 port using ReactOS would be a really nice flexible, modular installer (debian-installer or d-i for short). I've had problems with the ros installer in the past, specifically I couldn't install on one system without a mouse. It also asked many questions, couldn't resize partitions... d-i is nice in that it can be used with about three prompts, has partition resizing, can download additional modules... I'd suggest checking it out (I feel like I'm starting to just advertise it). Fwiw, longhorn seems to boot from a CD to do it's graphical install that is supposed to have file system resizing. Can/does ReactOS support ELF? Alex Ionescu said that there's now an ELF loader [4]. If so, would there be anything special that would need to be done to run Linux binaries on ReactOS (beyond syscalls and porting dependencies)? Is there any advantages to the PE format? If ReactOS could support running Linux binaries it would be an easier sell to port Debian to ReactOS as it could reuse things that are already compiled for Debian. I believe the FreeBSD port (kFreeBSD that is) [5] re-uses some packages compiled for Linux. OTOH, PE would be a nicer way to go so that some support for MS Windows could be allowed... Or could MS Windows be made to support ELF? I'm afraid I also don't know much about the coff format. [1] http://lists.debian.org/debian-win32/ [2] http://www.debian.org/social_contract#guidelines (very similar or the same as the OpenSource definition) [3] http://lists.debian.org/debian-win32/2005/10/msg00003.html Message-id: <43663BFE.9010004(a)liddicott.com> [4] http://www.reactos.org/bugzilla/show_bug.cgi?id=293 [5] http://www.debian.org/ports/kfreebsd-gnu/ Drew Daniels Resume: http://www.boxheap.net/ddaniels/resume.html

20 years

Re: [ros-diffs] [chorns] 19566: Speed up compilation of ntoskrnl

by Alex Ionescu

Hi, Do these changes break the MSVC backend? Best regards, Alex Ionescu

20 years

DOSemu for ReactOS

by crashfourit

Could we port DOSemu (http://www.dosemu.org/) to ReactOS for Dos and Win16 support? -- My DeviantArt.com page: http://crashfourit.deviantart.com/ My FanFiction.net bio page: http://www.fanfiction.net/u/726606/ My Blog: http://crashfourit.blogspot.com/ America's Debate: http://www.americasdebate.com/

20 years

Registry is messed up

by Brandon Turner

I think the registry is messed up. desk.cpl isnt writing the wallpaper style values, SystemParametersInfoW isnt wrtiting the path, and IntSystemParametersInfo isnt able to read the wallpaper settings from it. Also, my livecd wont boot with an error about not finding the codepage. This all leads me to believe that something is up with the registery. The last update i have is w3seek's where he reverted filip's registry changes. I dont know when this started happening, last day or so. It all worked fine when i commited 19476. Royce: The reason you werent getting the bugcheck with my stretch patch was because desk.cpl wasnt writing the wallpaper style values to the registry and tat is why the wallpaper didnt stick. I'm kinda busy right now. But hopfully within an hour I will be free and be able to do some more debuging. Brandon

20 years

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