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
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
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
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
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.
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.
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; }
>
>
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
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
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
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
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
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
Hello,
I need to use NDIS NdisIMRegisterLayeredMiniport functions to provide a virtual ethernet card. I read the documentation on MSDN and it seems that this functions is required to build an adapter without physical link (eg, with no hardware IRQ).
The problem is that this function is not implemented yet on reactos (svn rev. 62083). Is someone can tell me if it's implementable or if there is an alternative to build a virtual ethernet adapter with current implementation of NDIS.
Thanks.
--
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
14:02:53 up 1 day, 21:38, 1 user, load average: 0.17, 0.26, 0.23
Hi guys !
It seems to appear that some games need standard APIs hotpatchable, in the
sense of MS: few extra bytes present in the prologue of the functions that
allow somebody to detour the API. I knew that this feature was useful for
windows updates, but what I didnt know is that there are other programs
that use it: see this answer from James on the Epic Win! forum thread:
http://www.reactos.org/forum/viewtopic.php?f=2
<http://www.reactos.org/forum/viewtopic.php?f=2&t=10972&p=106823#p106814>
&t=10972&p=106823#p106814 , and the following post is something that Ive
found about this subject, and the fact that Wine already have done something
about that.
So my question: should we support/create hotpatchable images (of the
standard dlls and maybe ?? exes) in ReactOS ? Is it already done ? If not,
what needs to be added ? It seems that MSVC and GCC handle that a bit
differently.
Cheers,
Hermès BÉLUSCA - MAÏTO
Hello!
I have registered on main site, because I want to login to JIRA, but
JIRA says now that my login is incorrect. Does it need some time to make
JIRA accout accessible after registration? Or I need to do some actions?
Do I need to request account for JIRA separately?
Hi all,
In the process of improving the performance of our website and finally
getting rid of old.reactos.org, I'm moving away the Testman database to
a new VM tomorrow.
This will cause a short downtime, in which you're unable to browse
Testman results or submit new ones. Even if something goes wrong during
that process, the downtime shouldn't last longer than 2 hours.
With best regards,
Colin
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of this month, 27th of February, 19:00 UTC. Put that into your
calendars so you don't forget. And that's in two days!
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.
The agenda will be posted shortly before the meeting, suggestions are
welcome (send them to me shortly before the meeting starts).
Regards,
Aleksey Bragin
-------- Original Message --------
Subject: [ReactOS Deutschland e.V.] Your organization application has
been rejected.
Date: Mon, 24 Feb 2014 18:40:28 +0000
From: no-reply(a)google-melange.appspotmail.com
To: amine.khaldi(a)reactos.org
Thank you for submitting ReactOS Deutschland e.V.'s application to
Google Summer of Code 2014. Unfortunately, we were unable to accept your
organization's application at this time. Every year we receive many more
applications than we are able to accommodate, and we would encourage you
to reapply for future instances of the program.
If you would like some general feedback on why your organization was not
accepted, please consider attending the IRC meeting in #gsoc on Freenode
on Friday, 28 February, 2014 at 16:00 UTC. Please note that the feedback
meeting will be limited to the first 50 organizations to queue up
(queuing in the channel will begin at 15:30 UTC).
Best regards,
Could somebody visit and represent ReactOS to VIA Embedded at Embedded World 2014?
http://www.embedded-world.de/en/
February 25th - 27th in Nuremberg Germany
--
Best regards,
Alexander Rechitskiy