[CC] dll/win32/kernel32/file/file.c
cc1: warnings being treated as errors
dll/win32/kernel32/file/dir.c:21: error: 'gDebugChannel' defined but not used
make: *** [/mnt/ramdisk/buildbot/release/obj/dll/win32/kernel32/file/dir_kernel32.o]
Error 1
make: *** Waiting for unfinished jobs....
Hello,
After the switch in 48124 to PE FreeLDR, I am unable to boot FreeLDR any longer.
I have tried official, as well as various unofficial freeldr.sys, none worked.
47892 version works fine, 48124 does not.
On a 512MB IDE disk, I got the "_" VGA cursor scrolling endlessly/randomly on the screen, before even seeing "Loading FreeLDR..."
With a 1GB SCSI disk, tested also with a 6GB IDE disk, it remains stuck at "Loading FreeLDR...".
This seems strange: "Now booting from fat partitions (looks like that's what sysreg does) works again. It's safe under the condition that the cluster size is at least 4352 bytes, which is true for harddisks of sizes bigger than 272MB. Booting from smaller fat disks, like floppy breaks when freeldr.sys gets fragmented, which should rarely happen."
Please advise.
-r
Hello all,
I have noticed, that pxefixup does not set IMAGE_SCN_MEM_NOT_PAGED flag
for read-only data section ".rdata". May it be, that it is problem
for my own build of tools
586-mingw32-gcc (GCC) 4.4.2 and
GNU ld (GNU Binutils) 2.20.51.20100608
I have fixed the problem by preparing modified LD script version
which collect object files .rdata section into .text section
for my driver build.
But .rdata is legitimate section and it is automatically
generated by GCC. I have not found information in Wiki
or list archives, that there is some way/patch to deal
with this situation. But if it is allowed, that WDM
driver binaries contains readonly section then data paging
could lead to horrible consequences. Possible fix
diff --git a/reactos/tools/pefixup.c b/reactos/tools/pefixup.c
index f908a9a..d6ec1f4 100644
--- a/reactos/tools/pefixup.c
+++ b/reactos/tools/pefixup.c
@@ -381,6 +381,7 @@ int main(int argc, char **argv)
if (!strcmp((char*)section_header->Name, ".text") ||
!strcmp((char*)section_header->Name, ".data") ||
!strcmp((char*)section_header->Name, ".idata") ||
+ !strcmp((char*)section_header->Name, ".rdata") ||
!strcmp((char*)section_header->Name, ".bss"))
{
section_header->Characteristics |= htodl(IMAGE_SCN_MEM_NOT_PAGED);
If .rdata are not allowed or should be used only for pseudo_reloc,
then the ldscript for kernel code should be provided.
Missing flag for .rdata section in objdump ouput
$ i586-mingw32-objdump --headers ul_wdm.sys
BFD: ul_wdm.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .text
BFD: ul_wdm.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .data
BFD: ul_wdm.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .bss
BFD: ul_wdm.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .idata
ul_wdm.sys: file format pei-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0000cabc 00011000 00011000 00001000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 000000e8 0001e000 0001e000 0000e000 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .rdata 00003c20 0001f000 0001f000 0000f000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .bss 00000050 00023000 00023000 00000000 2**2
ALLOC
4 .edata 00000033 00024000 00024000 00013000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .idata 000008c4 00025000 00025000 00014000 2**2
CONTENTS, ALLOC, LOAD, DATA
6 .rsrc 0000035c 00026000 00026000 00015000 2**2
CONTENTS, ALLOC, LOAD, DATA
7 .reloc 00000cd4 00027000 00027000 00016000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .rossym 0001576d 00028000 00028000 00017000 2**2
CONTENTS, READONLY, NEVER_LOAD, EXCLUDE
Hi folks,
did anyone already do some research on whether ReactOS could
run in lguest ?
Maybe this could be a nice for development/debugging and
attracting more people ;-)
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt(a)metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
As we progress into regression fixing, we are now in the good moment to
decide upon upcoming release. It would be great if we could manage with the
0.3.12 for the October Chemnitz event, where we are invited again to
participate, not to mention that its the time for such release.
Right now, in my opinion we should decide without futher delay on the
following:
- reviewing the REGRESSION list, this is - to confirm entries with 0.3.12
milestone already set, as well as doublecheck the rest, to see if any should
be promoted to said milestone. This is the action of most utter importance,
as there is no way to know how much time will be spent on futher research,
testing and fixing them;
- decide upon bugs originated with last ole/comctl sync - are we haxing them
locally, risking another winesync or perhaps reverting?
- reviewing patches stored at http://www.reactos.org/wiki/Bug_Filters as
well as deciding if any should be adapted for current release.
Those actions, first of them especially, should be performed as swift as
possible, else we might risk considerable delay and nervous finish before
the Chemnitz.
hello,
this is to sir_richard, mostly,
i got this crash (assert) when shutting down ReactOS with the VirtualBox
Guest Additions installed.
i think the video driver is guilty for some reason i cannot understand...
probably you know :)
http://www.reactos.org/paste/index.php/7731/
Hello to all ReactOS developers,
thanks for great work. I introduce our case first.
--------------------------------------------------------------------
We have developed, maintain and use uLan RS-485 multi-master protocol
for years - sources traced to 1992 year. The protocol is used by
multiple companies and individuals for broad range of applications
from laboratory instruments control, home automation to agriculture
feeding and milking systems. We started by Linux support. But due
to customers demand, we have added Windows KDM and later WDM
support as well. I remember, that pointer to our driver has been
mentioned as one of little fully open-source drivers available
for Windows on ReactOS list many many years ago.
The uLan project homepage
http://ulan.sourceforge.net/
The uLan driver code can be compiled for Linux, Windows NT KDM,
Win98/2k/Vista WDM, plain DOS, system-less ARM and other devices.
The old legacy UART, PCI addon cards and USB converters
are supported for Linux and WDM version. All builds form same
sources with unification layer of macros which unifies systems
to something more close to Linux driver model. The code is
not so elegant and readable, the portability layers are quite
complex and sometimes hairy tasks. The traces of old age of
project can be seen there as well.
But it works and may it be, it could be some example
and source of helpers functions for porting of Linux
USB drivers to WDM model.
The ReactOS has got to the stage where it is able to run one
of our user applications utilizing our control protocol link.
Because I believe in open technologies, I would be very
happy if the project is usable even on RectOS - even that
I do not expect that our users could and want to switch
anytime soon or ever.
The Open Chromatography Station - CHROMuLAN
http://sourceforge.net/projects/chromulan/
If you think that it worth, it can be added to the
list of applications working with ReactOS 0.4-git/svn.
--------------------------------------------------------------------
As for the uLan driver. I have maneged it build for WDF with PCI
and UART support only to run on ReactOS and whole CHROMuLAN
setup seems to be functional.
I have even interrest to build driver code with ReactOS to test it more,
find incompatibilities and continue with 64-bit testing in future.
The effort seems to be not so far form success. The driver builds
with RectOS build under Linux when USB support is disabled.
The build with USB seems to be near as well.
There are two main problems:
1) We need to include usbdlib.h in the driver build, but DECLSPEC_EXPORT
in this header is not declared/maintained. We use this file
for next types declaration
USBD_INTERFACE_LIST_ENTRY
PUSBD_INTERFACE_LIST_ENTRY
struct _USBD_INTERFACE_LIST_ENTRY'
May it be, we should use different include headers, but next setup
works for years with Microsoft WDF
#include "wdm.h"
#include "usbdi.h"
#include "usbdlib.h"
2) If we overcome by some hack problem 1) the link fails on undefined
references to
__imp__USBD_ParseConfigurationDescriptorEx@28
__imp__USBD_CreateConfigurationRequestEx@8
There seems to be traces of implementation of these functions
in ReactOS old/disabled USB code. The functions are even included
in usbd.sys, usbd.exp and drivers/usb/usbd . But import library seems
to be missing. Am I right? Is there way to use them or plan to solve
that.
Thanks for reply in advance. Even that we do not much expect to use
ReactOS build in production environment the option has value for us.
It allows to test Windows builds in Linux environment without
need to start Wine for WDF. ReactOS build even helped us to find
some real bugs in our code because rectos runtime is more strict
in some checks then Windows systems.
Please, keep my email addres in reply, I do not expect (have ability)
to follow ReactOS development closely between my other duties.
It is unfortunate a little, that only way to contact developers
on the list is to subscribe.
Best wishes,
Pavel
--
Pavel Pisa
e-mail: pisa(a)cmp.felk.cvut.cz
www: http://cmp.felk.cvut.cz/~pisa
university: http://dce.fel.cvut.cz/
company: http://www.pikron.com/