Ros-dev

ros-dev@reactos.org

1 participants
5791 discussions

Possible Compiler/Library problem?
by TwoTailedFox 28 Nov '05

28 Nov '05

http://neowin.ath.cx/twotailedfox/Error.png Can anyone help me shed some light on this rather perculiar error? GCC 3.4.4/G++ 3.4.2, MSYS 1.0, GNU Make 3.80, NASM 0.98, Binutils 2.16.91, MinGW 4.1.0 -- "I had a handle on life, but then it broke"

1 0

Re: [ros-diffs] [sedwards] 19673: more crt, crtdll and msvcrt cleanup
by Thomas Weidenmueller 27 Nov '05

27 Nov '05

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

2 1

Re: [ros-svn] [ion] 19693: - Remove KTSS_NOIOMP from NDK.
by Alex Ionescu 27 Nov '05

27 Nov '05

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

2 2

Do it right first time ??
by Biera Gaino 27 Nov '05

27 Nov '05

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

3 2

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 27 Nov '05

27 Nov '05

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

3 3

Re: [ros-dev] [Vote] Top-level source header
by Brandon Turner 27 Nov '05

27 Nov '05

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. >

1 0

Re: [ros-diffs] [turner] 19669: Don't hardcode user to .DEFAULT when reading registry
by Thomas Weidenmueller 27 Nov '05

27 Nov '05

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

1 0

Debian win32 port, file system, installer, ELF
by Drew Scott Daniels 27 Nov '05

27 Nov '05

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

3 2

Re: [ros-diffs] [chorns] 19566: Speed up compilation of ntoskrnl
by Alex Ionescu 27 Nov '05

27 Nov '05

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

6 10

DOSemu for ReactOS
by crashfourit 27 Nov '05

27 Nov '05

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/

4 5

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