Ros-dev March 2014

ros-dev@reactos.org

18 participants
21 discussions

Installing driver without reboot
by Maxime Daniel 28 Mar '14

28 Mar '14

Hi, Is it possible to install a driver (virtual network interface) witout reboot the system ? I tried TAP interface (installation with devcon: devcon install inf-file tap0901) but the interface is only loaded during the next reboot (same for a ndis sample from DDK) Is there a way to load a driver interface with a true plug'n'play mechanism ? -- Daniel Maxime Linux version 3.6.9-maxux64 (emy) (gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5) ) #3 SMP PREEMPT Wed Feb 19 16:40:22 CET 2014 16:33:29 up 24 days, 8 min, 1 user, load average: 0.31, 0.68, 0.72

1 0

Re: [ros-dev] Installing and running ReactOS on modern hardware
by Thomas Mueller 28 Mar '14

28 Mar '14

from "David Quintana (gigaherz)" <gigaherz(a)gmail.com>: > [-- Type: multipart/alternative, Encoding: 7bit, Size: 5.8K --] > Content-Type: multipart/alternative; boundary=001a1135f7ac55c1ca04f557713d > Content-Type: text/plain; charset=UTF-8 > First of all, I'm not an expert when it comes to what ReactOS supports in > terms of real hardware. > I believe (someone will correct me if I'm wrong), that ReactOS is not > currently able to boot from USB, and in fact, will fail to boot at all if > an incompatible USB controller (which is most of them, I think?) is > present. Burning a CD-ROM with the setup or livecd images, and possibly > disabling the USB controllers from your bios config, may give you better > results. > I'm assuming that your intention is to try ReactOS in real hardware, > otherwise it would be better advised to just use VMware, VirtualBox, or > QEMU, as those work mostly out of the box. > Ideally, your real-hardware testing platform should have a serial port, and > this serial port should be connected to another computer with a serial > port, by using a null-modem cable. This way you could see debug messages > through the serial port, and interact with the remote debugger driver when > (more than if) it crashes. > ReactOS currently only supports FAT32, because it's a simple driver that > does not need advanced features of the storage system. As the storage stack > improves, it will be possible to attempt using more complex drivers. We > already have an EXT2 driver, but last I heard it was not stable enough to > be able to boot from it. > That's all I know. If it's not enough, maybe someone with more experience > can add to it. Thanks for response, but surely one-part plain text would be better than multipart/alternative? I could try commands such as drivemap in GRUB 2, but then ReactOS would be lost when trying to boot. Would MS-Windows drivers work in ReactOS when running from within VirtualBox or QEMU? I don't really want to try ReactOS on the same disk with FreeBSD and Linux installations that I want to keep intact, might be too hazardous. I don't have any serial ports but have serial headers on motherboard, could conceivably make a serial port. FreeDOS can boot from USB stick thanks to recognition by the BIOS/UEFI. I really would want to install ReactOS to something rewritable; having to burn a new CD for every little change is too much. With ReactOS being far from ready for production use, I figure I would have to make frequent changes/adjustments. I downloaded the installation iso for ReactOS 0.3.15, burned to CD, but that failed to boot. I believe Linux and *BSD are far more flexible in where they can install to than MS-Windows or OS/2. I hope ReactOS could rise above such Windows booting limitations. I ran OS/2 from 16-bit 1.3 in 1990 or 1991 to OS/2 Warp 4 in the single-digit days of April 2001. Then following a crash, on the next boot, CHKDSK, which ran automatically on the uncleanly-dismounted file system, ran amok and trashed everything on the hard drive. I was never again able to boot OS/2 after that. Now Linux and FreeBSD capabilities seem to far surpass OS/2 and its successor eComStation. Tom

2 4

Status Meeting (March 2014)
by Aleksey Bragin 27 Mar '14

27 Mar '14

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 27th of March, 19:00 UTC. Put that into your calendars so you don't forget. 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. Regards, Aleksey Bragin

2 1

ndis netvmini adapter
by Maxime Daniel 27 Mar '14

27 Mar '14

Hi, I'm trying to compile and test the netvmini ndis 5 adapter code from WDK, at first to understand how it works, then to modify it for another purpose. At this time I: - put the code on driver/network/dd/netvmini and adapted CMakeLists - put the inf on media/inf and adapted CMakeLists - fixed the code, it builds - add an entry to hivesys.inf to load the driver at boot The driver is well displayed during boot, debug message appears (the DriverEntry), on NtObj, the driver is visible and it appears on "Non Plug and Play" on device manager. Now, I don't know exactly what to do with it. How can I call the driver and add an adapter ? The userland tool given with the code works (I needed to comment some functions and add _DEV_BROADCAST_HANDLE struct by hand, it seems to not be implemented on dbt.h). When I run the userland tools, it fails with EnumDevices. Some help ? Thanks

2 1

Resuscitating MSVC 2008 builds (at least) for testing purposes only :P
by Hermès BÉLUSCA - MAÏTO 26 Mar '14

26 Mar '14

Because I was recently shocked (if I may say :D) that, for building a 2003-class operating system, we need 2010+ tools, I was wondering whether it was still possible to build ReactOS with MSVC 2008 and 2005. Ive created a task for that in Jira: http://jira.reactos.org/browse/CORE-8023 . After application of the configure.cmd patch that I give in the report, plus few tweaks in two headers (and adding some stdint.h in the correct directory for MSVC, needed for compiling host-tools, because this file is not included in default MSVC installation until MSVC 2010+), I was able to build a full bootcd and livecd (see the details in the abovementioned report, basically it currently builds with MSVC 2008 but not 2005). However there happens an interesting thing: the [boot|live]cd boots (freeldr seems to work and load the kernel and drivers), but after that, the kernel (debugged in WinDbg) hangs indefinitely here: Windows Server 2003 Kernel Version 3790 UP Checked x86 compatible Built by: 20140326-r62565 Machine Name: Kernel base = 0x80400000 PsLoadedModuleList = 0x005fcf88 System Uptime: not available (f:\ros_vs_test\ntoskrnl\ke\i386\cpu.c:494) Supported CPU features : KF_V86_VIS KF_RDTSC KF_CR4 KF_CMOV KF_GLOBAL_PAGE KF_LARGE_PAGE KF_MTRR KF_CMPXCHG8B KF_MMX KF_WORKING_PTE KF_PAT KF_FXSR KF_FAST_SYSCALL KF_XMMI KF_XMMI64 KF_NX_BIT (f:\ros_vs_test\ntoskrnl\ke\i386\cpu.c:801) Prefetch Cache: 64 bytes L2 Cache: 0 bytes L2 Cache Line: 64 bytes L2 Cache Associativity: 0 <_hangs_forever_here_> If some of you have an idea what *might* happen there, Im all ears! Cheers, Hermès.

2 1

Need assistance on bug 7965
by Alexander Varnin 26 Mar '14

26 Mar '14

Hello, dear developers! Sorry if I am doing something wrong, but I am not sure, if everyone who may help would be notified by JIRA. I made some bug hunting on CORE-7965 and now need some assistance in finding way to fix it. I have posted the results in my last comment on JIRA: http://jira.reactos.org/browse/CORE-7965?focusedCommentId=57456&page=com.at… In short: a bug is related to some interprocess virtual address transmission that is leading to access attempt on unallocated virtual memory, that finally crashes ReactOS.

1 0

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 26 Mar '14

26 Mar '14

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; } > >

3 5

Installing and running ReactOS on modern hardware
by Thomas Mueller 24 Mar '14

24 Mar '14

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

2 1

What's happening to the build bots??
by Hermès BÉLUSCA - MAÏTO 21 Mar '14

21 Mar '14

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

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 62480: [PSDK] winternl.h: Fix RtlLookupAtomInAtomTable prototype (should be sent to wine? not sure)
by Thomas Faber 20 Mar '14

20 Mar '14

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*); > >

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev March 2014