Ros-dev

ros-dev@reactos.org

5789 discussions

by Robert Naumann

Just a friendly reminder. The remaining time to participate becomes lesser and lesser. I still think we have good chances as this is organized by heise and they published much news about ros in the last year, so I think they are really interested. Here an English link: http://developerworld.heise.de/en/call-for-papers/ Am 04.12.2014 09:50 schrieb "Thomas Mueller" <mueller6723(a)twc.com>: > Hey guys, > I previously talked to daniel and colin about this thing and colin told me > to write a mail to this list. > I read about a big chance for the preject to show a presentation at the > CeBIT, the biggest german IT convention. > Sadly, I only have links to german websites but maybe you are satisfied > with google translation. > Here they are: > http://www.golem.de/news/call-for-papers-open-source-forum-sucht-experten-f… > http://www.linux-magazin.de/NEWS/Call-for-Papers-Open-Source-Forum-auf-der-… > This would be a big chance for the project as there are people from all > over the world and a bigger audience than the one of all Linux days > together could learn about the project. > Best Regards > Robert Sounds like a great idea. ReactOS could use the publicity, and it might recruit more developers to ReactOS. I have read about CeBIT on heise online (www.heise.de). Tom _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

10 years, 4 months

Re: [ros-dev] Question(s) about FreeLoader

by Rubén Mendoza Luna

> A final note, too (plus question): since our recent PXE support (that > appears to work! Thanks to Jérôme + Pierre effort, and numerous testers) > somebody oriented me to how this is done in Windows: they have a > STARTROM.0 file that is the bootstrap (downloaded and ran by PXE thing) > which then loads a NTLDR (somewhat). I binary analyzed it and it seems to be > of the same nature as the STPBOOT.BIN file, i.e. 16-bit bootstraper. > Question: does it load (after download) directly the 32-bit OSLOADER? OR > does it load the full NTLDR instead?, i.e. loading the 16-bit NTLDR part > (that then loads the 32-bit part)? StartROM.0 (called startrom.com and startrom.n12 ins the installation media) loads only a 32/64bit PE Setupldr.exe/Osloader.exe image, which is included with every Windows versión based in the NT Kernel, in a compressed form ofc, that's definitive. StartROM.0 is in effect the rought equivalent to STPBOOT.BIN in your example, but enabled for PXE booting. The confusión comes because StartROM expects to find the loader image with the specific NTLDR file name, renaming process which is done by the built-in Windows Server RIS server, when you créate a Windows distribution directory with the provided tools.

10 years, 4 months

Question(s) about FreeLoader

by Hermès BÉLUSCA - MAÏTO

Hi all, Ive some questions/remarks about FreeLoader. But first lets start with some introduction On Windows (up to 2k3, things changed starting Vista), the boot loader is in two flavours, the usual one (NTLDR) used for loading Windows when it is installed, and another one (SETUPLDR) used only for text-mode setup. NTLDR shows the classical OS menu (as we do in ReactOS), whereas SETUPLDR can be seen when you boot with a Windows setup CD: it shows some kind of text-mode blue-screen, displaying in a status bar the status of loading some boot-time drivers, possibly allowing you to press a function key to be able to give additional drivers to be loaded. After that, things are loaded (HAL, kernel) and the text-mode setup program proper is loaded (usetup.exe aka smss.exe in the disc). Whichever bootloader being considered, it is made of two parts (concatenated): - a 16 (real-mode)-to-32 bits part, lets call it STPBOOT.BIN (to follow the convention of http://reboot.pro/topic/5900-make-your-own-nt-os-loader-ntldrsetupldr/ ), - and a 32-bit one. The 16-bit part is some kind of stub which switches the CPU to 32 bit (and may also contain some utility functions to make real-mode callbacks). This stub is the same for both NTLDR and SETUPLDR, whereas the 32-bit part differs. In the Windows CD, in the \I386 directory you have those files, NTLDR and SETUPLDR.BIN. But if you analyze them, and after noticing the (compressed) files OSLOADER.NT_ (that expands to OSLOADER.NTD, but is in fact a native .EXE), and SETUPLDR.EX_ (that expands to SETUPLDR.EXE, also native EXE), you notice that in fact NTLDR == STPBOOT.BIN + OSLOADER.EXE and SETUPLDR.BIN == STPBOOT.BIN + SETUPLDR.EXE . (EDIT: During writing this mail I discovered that http://en.wikipedia.org/wiki/Windows_NT_startup_process#CD-ROM_boot_image_ph ase mentions the same thing in the Boot loader phase paragraph). On ReactOS we do the same: our FREELDR.SYS is made of a 16-bit part FRLDR16.BIN concatenated with FREELDR_PE.DLL (using the names of the generated files when you compile ROS). Also we had two targets, FREELDR and SETUPLDR, the former for generating the usual boot loader whereas the latter was used for the bootcd. However starting revision 65832 (http://svn.reactos.org/svn/reactos?view=revision <http://svn.reactos.org/svn/reactos?view=revision&revision=65832> &revision=65832 ) both SETUPLDR and FREELDR became the same. Why? What differed them was the support of the boot loading option ReactOSSetup: SETUPLDR was in fact FREELDR *with* the support of this option (in some revisions ago there was also support for some setup-like blue UI, see revision 57933: http://svn.reactos.org/svn/reactos?view=revision <http://svn.reactos.org/svn/reactos?view=revision&revision=57933> &revision=57933 and references within). Starting r65832 the setup support is automatically included in FREELDR. Therefore when we generate the bootcds, we generate a FREELDR and a SETUPLDR but both files are the same binary-wise. Hence the question: Should we still keep the SETUPLDR target, or just directly use FREELDR in all situations?. One may say keep it for compatibility purposes (filename-wise), but then one might just keep only the setupldr.sys file in the bootcd (and remove the freeldr.sys one)? Another question would be: Should we restore a SETUPLDR target (i.e. put setup-oriented code for SETUPLDR only and not in the usual FREELDR) in order to be able, in the future, to implement some sort of on-demand extra driver loading, as Windows SETUPLDR does? A final note, too (plus question): since our recent PXE support (that appears to work! Thanks to Jérôme + Pierre effort, and numerous testers) somebody oriented me to how this is done in Windows: they have a STARTROM.0 file that is the bootstrap (downloaded and ran by PXE thing) which then loads a NTLDR (somewhat). I binary analyzed it and it seems to be of the same nature as the STPBOOT.BIN file, i.e. 16-bit bootstraper. Question: does it load (after download) directly the 32-bit OSLOADER? OR does it load the full NTLDR instead?, i.e. loading the 16-bit NTLDR part (that then loads the 32-bit part)? Answers and comments are highly welcome!! Happy new year to everyone! Hermès.

10 years, 4 months

Re: [ros-dev] [ros-diffs] [pschweitzer] 65856: [NTOSKRNL] - Implement IopGetDeviceAttachmentBase() which allows getting the base device of the device stack given any device object in it - Implement IopGetDevicePDO() which r...

by Thomas Faber

On 2014-12-28 11:05, pschweitzer(a)svn.reactos.org wrote: > +extern ERESOURCE IopSecurityResource; This resource is only ever acquired shared, meaning it doesn't provide any mutual exclusion at all. Is that intentional?

10 years, 4 months

Re: [ros-dev] [ros-diffs] [hbelusca] 65449: [KERNEL32][CONSRV] - Remove the USE_CONSOLE_INIT_HANDLES define since now we "support" the console initialization events. - The events in the CONSOLE_START_INFO structure are cons...

by Thomas Faber

On 2014-11-22 23:13, hbelusca(a)svn.reactos.org wrote: > + Status = NtCreateEvent(&Console->InputBuffer.ActiveEvent, EVENT_ALL_ACCESS, > + &ObjectAttributes, NotificationEvent, FALSE); > + if (!NT_SUCCESS(Status)) > + { > + return STATUS_UNSUCCESSFUL; > + // return Status; > + } This was a while ago, but I'm curious: what's the point of this? Avoiding STATUS_UNSUCCESSFUL is usually a good thing.

10 years, 4 months

Re: [ros-dev] [ros-diffs] [jimtabor] 65815: [NtUser] - Crash while in recursion through hook calls. Move fast calls to api. Placed safe guards for removing message queue structures. Lock threads while calling hooks. Just ad...

by Thomas Faber

On 2014-12-23 20:05, jimtabor(a)svn.reactos.org wrote: > @@ -732,6 +732,7 @@ > return NULL; > } > > + RtlZeroMemory(Message, sizeof(Message)); > RtlMoveMemory(&Message->Msg, Msg, sizeof(MSG)); > > return Message; You mean sizeof(*Message)

10 years, 4 months

Re: [ros-dev] [ros-diffs] [gadamopoulos] 65766: [COMCTL32] * Do not add two additional pixels at the top margin of the toolbar. This is the behaviour of comctl32 v6 and our explorer depends on that to appear properly. We do...

by Alex Ionescu

Isn't the correct solution to use SxS with an activation context? Best regards, Alex Ionescu On Sun, Dec 21, 2014 at 1:49 AM, <gadamopoulos(a)svn.reactos.org> wrote: > Author: gadamopoulos > Date: Sat Dec 20 16:49:31 2014 > New Revision: 65766 > > URL: http://svn.reactos.org/svn/reactos?rev=65766&view=rev > Log: > [COMCTL32] > * Do not add two additional pixels at the top margin of the toolbar. This > is the behaviour of comctl32 v6 and our explorer depends on that to appear > properly. We don't have a proper solution for these differences in behavior > and since we already opt to use the v6 behavior I think it is fine. > > CORE-5483 #resolve #comment Committed a slightly different version of the > patch, thanks. > > Modified: > trunk/reactos/dll/win32/comctl32/toolbar.c > > Modified: trunk/reactos/dll/win32/comctl32/toolbar.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/comctl32/toolbar… > > ============================================================================== > --- trunk/reactos/dll/win32/comctl32/toolbar.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/comctl32/toolbar.c [iso-8859-1] Sat Dec 20 > 16:49:31 2014 > @@ -244,7 +244,12 @@ > > static inline int default_top_margin(const TOOLBAR_INFO *infoPtr) > { > +#if 0 > return (infoPtr->dwStyle & TBSTYLE_FLAT ? 0 : TOP_BORDER); > +#else > + /* This is the behaviour in comctl32 v6 */ > + return 0; > +#endif > } > > static inline BOOL TOOLBAR_HasDropDownArrows(DWORD exStyle) > > >

10 years, 4 months

by David Quintana

Ideally, we'd fork comctl32 into two libraries like windows does, but that would probably mean we'd have to fork from wine, moving the maintenance effort to our side. That's why we did not do it yet. Sent from my Windows Phone ------------------------------ From: Alex Ionescu Sent: 21/12/2014 09:05 To: ReactOS Development List Cc: Linda Wang; Filip Subject: Re: [ros-dev] [ros-diffs] [gadamopoulos] 65766: [COMCTL32] * Do not add two additional pixels at the top margin of the toolbar. This is the behaviour of comctl32 v6 and our explorer depends on that to appear properly. We do... Isn't the correct solution to use SxS with an activation context? Best regards, Alex Ionescu On Sun, Dec 21, 2014 at 1:49 AM, <gadamopoulos(a)svn.reactos.org> wrote: > Author: gadamopoulos > Date: Sat Dec 20 16:49:31 2014 > New Revision: 65766 > > URL: http://svn.reactos.org/svn/reactos?rev=65766&view=rev > Log: > [COMCTL32] > * Do not add two additional pixels at the top margin of the toolbar. This > is the behaviour of comctl32 v6 and our explorer depends on that to appear > properly. We don't have a proper solution for these differences in behavior > and since we already opt to use the v6 behavior I think it is fine. > > CORE-5483 #resolve #comment Committed a slightly different version of the > patch, thanks. > > Modified: > trunk/reactos/dll/win32/comctl32/toolbar.c > > Modified: trunk/reactos/dll/win32/comctl32/toolbar.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/comctl32/toolbar… > > ============================================================================== > --- trunk/reactos/dll/win32/comctl32/toolbar.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/comctl32/toolbar.c [iso-8859-1] Sat Dec 20 > 16:49:31 2014 > @@ -244,7 +244,12 @@ > > static inline int default_top_margin(const TOOLBAR_INFO *infoPtr) > { > +#if 0 > return (infoPtr->dwStyle & TBSTYLE_FLAT ? 0 : TOP_BORDER); > +#else > + /* This is the behaviour in comctl32 v6 */ > + return 0; > +#endif > } > > static inline BOOL TOOLBAR_HasDropDownArrows(DWORD exStyle) > > >

10 years, 4 months

Status Meeting

by Aleksey Bragin

Hey, since we skipped the meeting this week, I propose we do make a joint November-December meeting somewhere in the middle of December. (as we did in the previous year too). How about 18th of December? Regards, Aleksey Bragin

10 years, 4 months

Re: [ros-dev] [ros-diffs] [akhaldi] 65617: [USER32] We're not using any debugging routines here.

by Timo Kreuzer

Honestly, I don't see any point in these modifications. The next time someone wants to use these debug routines, he will need to add it back. Or he will start using DPRINT stuff again. I'd prefer to have this in all files! Am 12.12.2014 14:23, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Fri Dec 12 13:23:45 2014 > New Revision: 65617 > > URL: http://svn.reactos.org/svn/reactos?rev=65617&view=rev > Log: > [USER32] We're not using any debugging routines here. > > Modified: > trunk/reactos/win32ss/user/user32/misc/rtlstr.c > > Modified: trunk/reactos/win32ss/user/user32/misc/rtlstr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/user32/misc/r… > ============================================================================== > --- trunk/reactos/win32ss/user/user32/misc/rtlstr.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/user32/misc/rtlstr.c [iso-8859-1] Fri Dec 12 13:23:45 2014 > @@ -10,10 +10,6 @@ > /* INCLUDES ******************************************************************/ > > #include <user32.h> > - > -#include <wine/debug.h> > - > -WINE_DEFAULT_DEBUG_CHANNEL(user32); > > /* FUNCTIONS *****************************************************************/ > VOID > > >

10 years, 4 months

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