uLan USB driver for ReactOS - query for help if possible

[Pavel Pisa]

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:     [e-mail]
    www:        http://cmp.felk.cvut.cz/~pisa
    university: http://dce.fel.cvut.cz/
    company:    http://www.pikron.com/

[Amine Khaldi]

Hello Pavel,
> 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:
>
> 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"
>
> 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:[e-mail]
>      www:http://cmp.felk.cvut.cz/~pisa
>      university:http://dce.fel.cvut.cz/
>      company:http://www.pikron.com/

I have addressed your first problem in r48774. Please retest and report 
any further issues.
Re. contacting the developers, you're welcome to join our IRC channels 
for a real-time discussion: http://www.reactos.org/en/community_irc.html

Regards,
Amine.

[Michael Martin]

Pavel,

Hi, I am the developer that is currently working on USB in ReactOS.
Problem 1 has already been fixed by Amine Khaldi.
As for problem 2, the usbd driver does indeed have these functions implemented
though i have not looked to see if they are correct. The usbd driver is currently built but
not added to the ReactOS.iso. To have it added, you need to modify
boot/bootdata/packages/reactos.dff.

Including the usbd in the rbuild file as a library will resolve the issue.

FYI, Our USB stack is no where near complete. 
We do plan on implementing all the drivers in the USB stack.

WBR,
Michael Martin
> From: [e-mail]
> To: [e-mail]
> Date: Wed, 15 Sep 2010 10:19:19 +0200
> Subject: [ros-dev] uLan USB driver for ReactOS - query for help if possible
>
> 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:
>
> 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"
>
> 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:     [e-mail]
>     www:        http://cmp.felk.cvut.cz/~pisa
>     university: http://dce.fel.cvut.cz/
>     company:    http://www.pikron.com/
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Pavel Pisa]

Hello Michael and Amine,

thanks for fast response. I have rebuild actual ReactOS sources
from GIT repository.
> > From: [e-mail]
> > To: [e-mail]
> > We need to include usbdlib.h in the driver build, but DECLSPEC_EXPORT
> > in this header is not declared/maintained.

On Wednesday 15 September 2010 11:04:27 Amine Khaldi wrote:
> I have addressed your first problem in r48774. Please retest and report
> any further issues.
> Re. contacting the developers, you're welcome to join our IRC channels
> for a real-time discussion: http://www.reactos.org/en/community_irc.html

The driver sources compile in WDM build from unmodified sources now. Great.
> > If we overcome by some hack problem 1) the link fails on undefined
> > references to
> >   __imp__USBD_ParseConfigurationDescriptorEx@28
> >   __imp__USBD_CreateConfigurationRequestEx@8

On Wednesday 15 September 2010 14:16:52 Michael Martin wrote:
> Pavel,
>
> Hi, I am the developer that is currently working on USB in ReactOS.
> Problem 1 has already been fixed by Amine Khaldi.
> As for problem 2, the usbd driver does indeed have these functions
> implemented though i have not looked to see if they are correct. The usbd
> driver is currently built but not added to the ReactOS.iso. To have it
> added, you need to modify boot/bootdata/packages/reactos.dff.
>
> Including the usbd in the rbuild file as a library will resolve the issue.

Please, could you guide me a little. I see two sub-problems.

If I understand well, the functions are provided by usbd.sys.
It seems to be included in LiveCD (output-i386/livecd/reactos/system32/drivers/)
but it is not included in BootCD and list of install files.

There is the second problem, that the driver build needs import library.
I have tried to generate it from obj-i386/drivers/usb/usbd/usbd_usbd.auto.def

i586-mingw32-dlltool --output-lib usbd.lib --input-def usbd_usbd.def

This way I build something which seems like WDM driver. There would be probably
problem with correct set of options for GCC and LD which I use for build.
I would prefer to specify these directly without calls to Rbuild.
I use next set of options now.

i586-mingw32-gcc -nostdinc -D _M_IX86 -D _M_IX86 -I /home/pi/repo/reactos/include/ddk \
  -I /home/pi/repo/reactos/include/psdk -I /home/pi/repo/reactos/include/crt \
  -I /home/pi/repo/reactos/include/crt/mingw32 -D FOR_WIN_WDM -Wall -Wno-unused \
  -D__NTDRIVER__ -D_DLL -D__USE_CRTIMP -D__REACTOS__ -DDBG=1 -D_SEH_ENABLE_TRACE -DKDBG=1 \
  -DWINVER=0x502 -D_WIN32_IE=0x600 -D_WIN32_WINNT=0x502 -D_WIN32_WINDOWS=0x502 \
  -D_SETUPAPI_VER=0x502 -D_USE_32BIT_TIME_T -D_M_IX86 -D_X86_ -D__i386__ \
  -DUSE_COMPILER_EXCEPTIONS -march=pentium -mtune=i686 -pipe -Wall -gstabs+ \
  -Os -fno-strict-aliasing -fno-unit-at-a-time -fno-optimize-sibling-calls \
  -ftracer -momit-leaf-frame-pointer -mpreferred-stack-boundary=2 -fno-common \
  -fno-zero-initialized-in-bss -c ul_drv/ul_drv.c -o ul_wdm.o

i586-mingw32-gcc -o ul_wdm.sys ul_wdm.o ul_wdm.def -Wl,-subsystem,native -Wl,-entry,_DriverEntry@8 \
  -Wl,-image-base,0x00010000 -Wl,-file-alignment,0x1000 -Wl,-section-alignment,0x1000 \
  -mdll -Wl,-stack,0x40000 -nostdlib -nostartfiles -L . usbd.lib -l hal -l ntoskrnl

./pefixup ul_wdm.sys -exports -sections

I try to prepare setup to test real uLan SB driver with ReactOS.
I would prefer to use KVM or Qemu. I have managed to install actual build
of ReactOS on disk image. I have checked that KMD uLan driver in virtual
(no real device) mode works even on this build.
> FYI, Our USB stack is no where near complete.
> We do plan on implementing all the drivers in the USB stack.

Yes I am fully aware of that, but it is interresting combination to test
and it could help us even to find problematic constructs in our driver.
I do not like to run any closed system myslef, so possibility to use
ReactOS (best with KVM a USB device tunneling) is very interresting for me.
Even actual possibility to build (may be even Windows/Ros incompatible)
driver binary under GNU/Linux is great to check, that changes in common
code parts do not (probably) cause breakage of Windows build.

During the history of my trials with ReactOS I have notices more
problems. May it be, that some symptoms could be of some help
for you. May be, that they are problem of my tools setup.

I use qemu-kvm-0.12.3 , own build of i586-mingw32-gcc 4.4.2 on AMD64
Debian system. GCC configured

configure -v --enable-languages=c,c++ --prefix=/usr --with-system-zlib
 --without-included-gettext --enable-shared --disable-nls --enable-mpfr
 --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
 --target=i586-mingw32 --enable-threads=win32 --disable-win32-registry
 --enable-version-specific-runtime-libs --disable-libgomp

Headers and import libraries are MSYS updated by HAL and some other from ReactOS.
I use that setup for Windows version of our tools builds too.

The actual version of RectOS requires next additional line for above
described setup

PROJECT_CXXLIBS += "$(shell ${TARGET_CPP} -print-file-name=libgcc_eh.a)"

My LiveCD build does not start under Qemu nor KVM. Logs attached.

The BootCD seems to start correctly. I have been able to reinstall
ReactOS in my older disk image. I have left filesystem unchanged
but when I have tried to install new boot record, loader fails
to start - blocks after loading freeldr message.
When older version of loader is left untouched, system comes up
without problems.

There seems to be some reproducible problem which seems to be
unrelated to our driver (virtual mode for now). When some
CHROMuLAN modal windows/dialogs are open the system freezes
on

err:(dll/win32/user32/windows/menu.c:3183) MenuTrackMenu 1
err:(dll/win32/user32/windows/menu.c:3429) MenuTrackMenu 2
.[7h.Entered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fault)
Memory at 0x00000004 could not be read: Page not present.
kdb:>

Any way, the amount of things which works under ReactOS and
amount of work which has been required for that to became
reality is impressive.

Best wishes,

Pavel

[Olaf Siejka]

> I would prefer to use KVM or Qemu.

You might try VirtualBOX as well, as its also supporting USB Tunneling to
vm.
> .[7h.Entered debugger on last-chance exception (Exception Code: 0xc0000005)

(Page Fault)
> Memory at 0x00000004 could not be read: Page not present.
> kdb:>

In this situation you should acquire backtrace for this crash, by simply
issuing bt command.

2010/9/16 Pavel Pisa [e-mail]
> Hello Michael and Amine,
>
> thanks for fast response. I have rebuild actual ReactOS sources
> from GIT repository.
> > > From: [e-mail]
> > > To: [e-mail]
> > > We need to include usbdlib.h in the driver build, but
>
> DECLSPEC_EXPORT
> > > in this header is not declared/maintained.
>
> On Wednesday 15 September 2010 11:04:27 Amine Khaldi wrote:
> > I have addressed your first problem in r48774. Please retest and report
> > any further issues.
> > Re. contacting the developers, you're welcome to join our IRC channels
> > for a real-time discussion: http://www.reactos.org/en/community_irc.html
>
> The driver sources compile in WDM build from unmodified sources now. Great.
> > > If we overcome by some hack problem 1) the link fails on undefined
> > > references to
> > >   __imp__USBD_ParseConfigurationDescriptorEx@28
> > >   __imp__USBD_CreateConfigurationRequestEx@8
>
> On Wednesday 15 September 2010 14:16:52 Michael Martin wrote:
> > Pavel,
> >
> > Hi, I am the developer that is currently working on USB in ReactOS.
> > Problem 1 has already been fixed by Amine Khaldi.
> > As for problem 2, the usbd driver does indeed have these functions
> > implemented though i have not looked to see if they are correct. The usbd
> > driver is currently built but not added to the ReactOS.iso. To have it
> > added, you need to modify boot/bootdata/packages/reactos.dff.
> >
> > Including the usbd in the rbuild file as a library will resolve the
>
> issue.
>
> Please, could you guide me a little. I see two sub-problems.
>
> If I understand well, the functions are provided by usbd.sys.
> It seems to be included in LiveCD
> (output-i386/livecd/reactos/system32/drivers/)
> but it is not included in BootCD and list of install files.
>
> There is the second problem, that the driver build needs import library.
> I have tried to generate it from
> obj-i386/drivers/usb/usbd/usbd_usbd.auto.def
>
> i586-mingw32-dlltool --output-lib usbd.lib --input-def usbd_usbd.def
>
> This way I build something which seems like WDM driver. There would be
> probably
> problem with correct set of options for GCC and LD which I use for build.
> I would prefer to specify these directly without calls to Rbuild.
> I use next set of options now.
>
> i586-mingw32-gcc -nostdinc -D _M_IX86 -D _M_IX86 -I
> /home/pi/repo/reactos/include/ddk \
>  -I /home/pi/repo/reactos/include/psdk -I /home/pi/repo/reactos/include/crt
> \
>  -I /home/pi/repo/reactos/include/crt/mingw32 -D FOR_WIN_WDM -Wall
> -Wno-unused \
>  -D__NTDRIVER__ -D_DLL -D__USE_CRTIMP -D__REACTOS__ -DDBG=1
> -D_SEH_ENABLE_TRACE -DKDBG=1 \
>  -DWINVER=0x502 -D_WIN32_IE=0x600 -D_WIN32_WINNT=0x502
> -D_WIN32_WINDOWS=0x502 \
>  -D_SETUPAPI_VER=0x502 -D_USE_32BIT_TIME_T -D_M_IX86 -D_X86_ -D__i386__ \
>  -DUSE_COMPILER_EXCEPTIONS -march=pentium -mtune=i686 -pipe -Wall -gstabs+
> \
>  -Os -fno-strict-aliasing -fno-unit-at-a-time -fno-optimize-sibling-calls \
>  -ftracer -momit-leaf-frame-pointer -mpreferred-stack-boundary=2
> -fno-common \
>  -fno-zero-initialized-in-bss -c ul_drv/ul_drv.c -o ul_wdm.o
>
> i586-mingw32-gcc -o ul_wdm.sys ul_wdm.o ul_wdm.def -Wl,-subsystem,native
> -Wl,-entry,_DriverEntry@8 \
>  -Wl,-image-base,0x00010000 -Wl,-file-alignment,0x1000
> -Wl,-section-alignment,0x1000 \
>  -mdll -Wl,-stack,0x40000 -nostdlib -nostartfiles -L . usbd.lib -l hal -l
> ntoskrnl
>
> ./pefixup ul_wdm.sys -exports -sections
>
> I try to prepare setup to test real uLan SB driver with ReactOS.
> I would prefer to use KVM or Qemu. I have managed to install actual build
> of ReactOS on disk image. I have checked that KMD uLan driver in virtual
> (no real device) mode works even on this build.
> > FYI, Our USB stack is no where near complete.
> > We do plan on implementing all the drivers in the USB stack.
>
> Yes I am fully aware of that, but it is interresting combination to test
> and it could help us even to find problematic constructs in our driver.
> I do not like to run any closed system myslef, so possibility to use
> ReactOS (best with KVM a USB device tunneling) is very interresting for me.
> Even actual possibility to build (may be even Windows/Ros incompatible)
> driver binary under GNU/Linux is great to check, that changes in common
> code parts do not (probably) cause breakage of Windows build.
>
> During the history of my trials with ReactOS I have notices more
> problems. May it be, that some symptoms could be of some help
> for you. May be, that they are problem of my tools setup.
>
> I use qemu-kvm-0.12.3 , own build of i586-mingw32-gcc 4.4.2 on AMD64
> Debian system. GCC configured
>
> configure -v --enable-languages=c,c++ --prefix=/usr --with-system-zlib
>  --without-included-gettext --enable-shared --disable-nls --enable-mpfr
>  --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
>  --target=i586-mingw32 --enable-threads=win32 --disable-win32-registry
>  --enable-version-specific-runtime-libs --disable-libgomp
>
> Headers and import libraries are MSYS updated by HAL and some other from
> ReactOS.
> I use that setup for Windows version of our tools builds too.
>
> The actual version of RectOS requires next additional line for above
> described setup
>
> PROJECT_CXXLIBS += "$(shell ${TARGET_CPP} -print-file-name=libgcc_eh.a)"
>
> My LiveCD build does not start under Qemu nor KVM. Logs attached.
>
> The BootCD seems to start correctly. I have been able to reinstall
> ReactOS in my older disk image. I have left filesystem unchanged
> but when I have tried to install new boot record, loader fails
> to start - blocks after loading freeldr message.
> When older version of loader is left untouched, system comes up
> without problems.
>
> There seems to be some reproducible problem which seems to be
> unrelated to our driver (virtual mode for now). When some
> CHROMuLAN modal windows/dialogs are open the system freezes
> on
>
> err:(dll/win32/user32/windows/menu.c:3183) MenuTrackMenu 1
> err:(dll/win32/user32/windows/menu.c:3429) MenuTrackMenu 2
> .[7h.Entered debugger on last-chance exception (Exception Code: 0xc0000005)
> (Page Fault)
> Memory at 0x00000004 could not be read: Page not present.
> kdb:>
>
> Any way, the amount of things which works under ReactOS and
> amount of work which has been required for that to became
> reality is impressive.
>
> Best wishes,
>        Pavel
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev