Hi,
I know that for some open source projects React OS sign's windows drivers.
Could you please sign the driver for virtual floppy drive?
Motivation:
Virtual Floppy drive is very helpfull, for example take freedos floppy image,
include Samsung SpinPoint F4 EcoGreen HD204UI firmware update into the image
and put it with unetbootin on usb stick.
Problem: virtual floppy drive didn't run on windows 7 x64 because the need of
driver signing.
Homepage:
http://vfd.sourceforge.net/
Description:
>This is a virtual floppy drive for Windows NT / 2000 / XP developed by Ken Kato
>(Reported to work also on 2003 Server and Vista). <-- and windows 7 x86, too.
>
>You can mount a floppy image file as a virtual floppy drive and directly access the contents --
>view, edit, rename, delete or create files on a virtual floppy, format a virtual floppy,
>launch a program on a virtual floppy... almost anything you can do with a real floppy.
vfdwin x64 driver build (unsigned) from "critical0"
http://sourceforge.net/projects/vfd/files/2.1%20(February%2006%2C%202008)/v…
vfdwin x64 driver build (unsigned) from "Igor Levicki"
http://levicki.net/downloads/sendfile.php?path=vfd_x64/vfd_x64.zip
Discussion about the different versions:
http://levicki.net/articles/stories/2007/08/17/The_story_of_the_vfdwin_21_6…
greetings
Carsten
dreimer(a)svn.reactos.org wrote:
> if not exist "CMakeLists.txt" (
Can we decide on dropping support for rbuild stuff in RosBE 2.0?
Reasons:
- RosBE 2.0 will certainly come with an updated set of build tools.
(GCC 4.6 with mingw-w64 target is planned, maybe even a multilib
version)
The target change already makes older builds uncompilable with RosBE
2.0. Even if this would be fixed, nobody would guarantee you that a
revision built with RosBE 2.0 behaves the same as one compiled with
1.5.x.
- Several versions of RosBE can be installed parallely, especially if
you're also moving to a Windows Installer for RosBE 2.0, which doesn't
care about Uninstall entries of NSIS. So everybody has the option
to build older rbuild-powered revisions at any time.
- It could make all scripts cleaner again :-)
Regards,
Colin
dreimer(a)svn.reactos.org wrote:
> Get the cmake path from a system variable called _ROSBE_CMAKEPATH.
I hope we're not thinking about requiring the user to install RosBE and
CMake separately.
This would pretty much kill the point of RosBE if people are forced to
get random versions of their build tools from multiple sources again..
- Colin
Same comment as before, resources MUST be acquired within a critical region (as the old code did).
--
Best regards,
Alex Ionescu
On 2011-06-02, at 1:43 PM, pschweitzer(a)svn.reactos.org wrote:
> /* Acquire the FS lock */
> - KeEnterCriticalRegion();
> - ExAcquireResourceExclusiveLite(&FileSystemListLock, TRUE);
> + ExAcquireResourceExclusiveLite(&IopDatabaseResource, TRUE);
jgardou(a)svn.reactos.org wrote:
> - set(_gch_filename "${_target_name}_${_FILE}.gch")
> + set(_gch_filename "${_FILE}.gch")
Looks like we're going through the same mess of GNU precompiled headers,
which we already had in rbuild:
1) Giving the GCH file a custom name.
Problem: It is simply ignored in the build process.
2) Just renaming it to the name of the header file.
Problem: If two modules use the same header file with different
build options (like #defines), the compiler can only choose one
precompiled header and we have a corrupted build.
The solution now is to give every GCH file an individual directory whose
name contains the module name (like ".gch_smlib", this is what we
currently have in rbuild).
Concluding from what I see in rbuild, please also note that the GCH file
needs to be named "header.h.gch", not "header.gch". Your ${basename}
variable sounds like this is not done either in the CMake branch.
- Colin
You are rebrowsing the *whole* list, yet the caller gave you an argument (DriverObjectListSize) that indicated to you how large his array is.
You should browse the minimum of the whole list while making sure that "Index" does not grow larger than DriverObjectListSize / sizeof(pointer).
Right now the function is overwriting memory possibly.
This is because + /* Then, check if given buffer is big enough to contain list */
+ if (ListSize > DriverObjectListSize / sizeof(PDRIVER_OBJECT))
+ {
+ Status = STATUS_BUFFER_TOO_SMALL;
+ }
+ else
is incorrect. The function attempts to write as many entries as possible instead of failing.
As per the docs:
" Note that if the array at DriverObjectList is too small, the number of driver object pointers that are copied into the array will be less than ActualNumberDriverObjects."
--
Best regards,
Alex Ionescu
On 2011-06-02, at 1:43 PM, pschweitzer(a)svn.reactos.org wrote:
> + /* Rebrowse the whole list */
> + ListEntry = IopFsNotifyChangeQueueHead.Flink;
> + while (ListEntry != &IopFsNotifyChangeQueueHead)
> + {
As per elementary Windows Driver Development basics, resources should ALWAYS be acquired within a critical or guarded region.
--
Best regards,
Alex Ionescu
On 2011-06-02, at 1:43 PM, pschweitzer(a)svn.reactos.org wrote:
> + /* Acquire the FS lock */
> + ExAcquireResourceExclusiveLite(&IopDatabaseResource, TRUE);
You misunderstand the meaning of the parameter. The last entry is the RAW file system. This parameter influences if RAWFS should be notified or not.
--
Best regards,
Alex Ionescu
On 2011-06-02, at 1:43 PM, pschweitzer(a)svn.reactos.org wrote:
> + /* Check if we reached end and if we have to skip it */
> + if (ListEntry->Flink == ListHead && SkipLast)
> + {