Just been in the #reactos channel and asked if there were any interesting
small tasks for me to work on, and was told to go to Bugzilla on the site. I
had difficulty finding it, so I asked and was told the link to the Bugzilla
page.
I was then told I needed to log in to see issues, so I clicked to register a
new account.
I was then told to go to the main page and to create an account from there.
However, I can't see anywhere on the page that says "register" or "create
account" or anything like that. Instead, it appears I have to click on Login
on the main page (incidentally I never actually noticed this link) and then
register from there.
It seems a bit awkward to me. Surely it'd make more sense to have a link to
registration and/or logging in right on on the main page? So that it sticks
out a bit more.
Just a suggestion. Apart from that I think the site's great!
Hello Okajima,
I understand even governments have budget limits but could you see
about getting ReactOS involved in Virtual Linux for Windows? Our system
clones the whole Windows NT/2k kernel enviroment. One of the goal of
VLW is to be free of cygwin at some point right? Maybe developing with
ReactOS will help with this.
Thanks
Steven
--- "Digital Infra, Inc." <okajima(a)digitalinfra.co.jp> wrote:
> ------------------------------------------------------------
> /*
> Virtual Linux for Windows.
> Sponsored by Japanese Govt. Software development dept.
> Exective producer: xxx yyy ( Chairman of the dept.)
> Senior producer : aaa bbb ( vice president of the dept.)
> ( and many lines of name.)
> dont miss names of any "bosses".
> otherwise you make them displeasure.
> and make it difficult to get next budget.
> Programmer:
> Chandan Kudige
> Dan Aloni
> Okajima, Jun (Digital Infra, Inc.)
> Copyright(C) 2004 Japanese Govt.(<-this line is necessary.)
> Licensed under GPL.
> */
> -----------------------------------------------------------
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
I am unable to use cvs anymore. I stand over an firewall that filter the
packets not on port 80. Is there a way to use proxy or somehow ???
If it is not possible is there a possibility to make source snapshots of
rectos like every 3 days an place it on site ?
Else, could anyone pack the cvs for this date and place it somwhere so i could
download the latest sources ?
Hello Jan!
--- Jan Kratochvil <lace(a)jankratochvil.net> wrote:
> Hi,
>
> On Mon, 10 Nov 2003 20:19:45 +0100, Rapha�l Junqueira wrote:
> ...
> > > BTW, I have got as far with loading secdrv.sys as crashing on
> unimplemented
> > > IoCreateDevice. I believe the Io* functions will be the biggest
> problems.
>
> It is no problem loading it and initializing it by Captive NTFS for
> GNU/Linux:
> http://www.jankratochvil.net/project/captive/
>
> ./captive-cmdline --load-module=/tmp/ntoskrnl.exe
> --filesystem=/tmp/secdrv.sys --debug-messages /dev/null
>
> (some trivia extensions done before a moment are currently only in
> CVS:
>
>
http://cvs.jankratochvil.net/viewcvs/*checkout*/captive/README?rev=HEAD
> section 'CVS Bleeding Edge'
> )
>
> 'secdrv.sys' creates devices:
> "\Device\AscKmd" (symlinked to "\DosDevices\AscKmd")
> "\Device\Secdrv" (symlinked to "\DosDevices\Secdrv")
>
> It returns STATUS_SUCCESS afterwards. The log can be seen at
> http://www.jankratochvil.net/priv/secdrv/secdrv-init-onlysecdrv.log
>
> I used secdrv.sys
> http://www.jankratochvil.net/priv/secdrv/secdrv.sys
> md5: bb6fbebebbd14429021f2851a60d8546
>
> downloaded by Google from
> http://www.kids-station.com/game/Patrician2/secdrv.sys
>
> Further run fails for Captive as 'secdrv.sys' is somehow broken
> driver as it
> does not provide any way to mount a filesystem. :-?
>
> Currently the example above requires 'ntoskrnl.exe' of NT-5.1 (XP).
> Tried Service Pack 1 Free Build and Service Pack 1 Checked Build.
> It would not be needed for such simple driver as 'secdrv.sys' but
> Captive
> currently requires it for its 'ntfs.sys' emulation, reasons below:
>
>
http://www.jankratochvil.net/project/captive/doc/Details.html.pl#emulmeth_fs
>
>
> The next step is to combine Captive with Wine to be able to run the
> W32
> userland application with 'secdrv.sys'. Captive ported only the W32
> kernel part
> of ReactOS to the GNU/Linux environment, no W32 userland code is
> present there.
Hmm. We really shouldnt need to make much changes to WINE to use
Captive I would think. Once Captive+SevDrv and WINE are running you
should have full access to the CDROM drive.
> > Well, i don't think implementing simple (stupid?) Io* functions
> will be
> > diffcult.
>
> (A)Synchronous/(Non)Alertable IRPs (I/O Request Packet) can be tricky
> although
> it is generally solved by ReactOS/Captive and it is questionable how
> much it is
> perused by 'secdrv.sys' IRP handling code.
We are still having trouble loading SecDrv.sys on native ROS.
> > For me, the problem is what secdrv want to do with this functions
> (maybe a
> > voodoo test for safely check if the subsystem have a correct
> behavior):
> ...
> > - - RtlUnwind
>
> This is a part of undocumented SEH (Structured Exception Handling)
> implemented
> by ReactOS while fixed by Captive and partially combined with native
> 'ntoskrnl.exe'. I still have some suspections on the correctness of
> the current
> implementation but it works fine for 'ntfs.sys'.
We have a new SEH implementation that is not merged yet. The
implementation we have is patent friendly as it implement SEH totaly
differntly by using macros kind of like WINE.
Its looking good!
Thanks
Steven
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
Hello,
--- Rapha�l_Junqueira <fenix(a)club-internet.fr> wrote:
> it is simple, only a PE module who work on kernel mode using os APIs:
>
> - -=(FeniX as fenix@DarkBluE)-(on tty2)-(at 13:39:31)=-
> -={$:'~'}=->winedump dump -j import
> /mnt/win_c2/windows/system32/drivers/
> secdrv.sys
> Contents of "/mnt/win_c2/windows/system32/drivers/secdrv.sys": 27440
> bytes
>
> Import Table size: 40
> offset 25404 ntoskrnl.exe
> Hint/Name Table: 00006364
> TimeDataStamp: 00000000 (Thu Jan 1 01:00:00 1970)
> ForwarderChain: 00000000
> First thunk RVA: 00000260 (delta: 4294967295 0xffffffff)
> Ordn Name
> 252 IoDeleteSymbolicLink 644a
> 251 IoDeleteDevice 63b4
> 247 IoCreateSymbolicLink 63c6
> 243 IoCreateDevice 63de
> 720 RtlInitUnicodeString 63f0
> 687 RtlEqualUnicodeString 6408
> 519 NtBuildNumber 6420
> 760 RtlQueryRegistryValues 6430
> 599 PsGetVersion 63a4
> 434 KeTickCount 6462
> 479 MmIsAddressValid 6470
> 792 RtlUnwind 6492
> 54 ExAllocatePoolWithTag 649e
> 66 ExFreePool 64b6
> 325 IofCompleteRequest 64c4
>
> Done dumping /mnt/win_c2/windows/system32/drivers/secdrv.sys
>
> The problem is how emulate windows kernel internal behavior (ie
> assembly tips
> as NtCurrentTeb)
We have been looking in to loading this driver under ReactOS and all of
the functions are implemented but it still returns STATUS_UNSUCESSFULL.
I think that the imports of "PsGetVersion and NtBuildNumber" might have
something to do with it. The driver works under my Windows NT 4 laptop
but not ReactOS. We may just have to hard code the values to match NT 4
and it could work.
If we can get it to load on ROS it will be up to you guys to figure out
a way to adapt ROS+WINE to play nice together. =)
Thanks
Steven
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
On Sun 9. November 2003 00:59, Jonathan Wilson wrote:
> Here is what happens on real windows under different cases:
> (note that anytime I refer to GetWindowLong, I also mean the return value
> one would get from calling SetWindowLong since its the same thing)
> Anytime I refer to [SetGet]WindowLong[AW], I refer to calling it with
> GWL_WNDPROC as the parameter
...
This all sounds reasonable.
We should implement it this way.
--
Martin Fuchs
martin-fuchs(a)gmx.net
Hi Guys,
The release candidate has been delayed. Had some problems building, we'll first have to check what's wrong. A second attempt will be made sunday.
Greets,
Nick
We are now able to load the standard NVidia video drivers for at least
NVidia Riva TNT2 Model 64 cards, but probably for more Nvidia based
cards. The attached file describes how to do that. Jason/Hyperion, can
you find space for that information on the website?
It doesn't work perfect yet. Not all lines are drawn (check the maze
demo), sometimes the mouse cursor is messed up, the hotspot for the
mouse cursor is in the wrong place (you need to point down-right of
where you want to click) and dragging the cards in Solitaire doesn't
work as it should. If you find other issues, please enter them in
Bugzilla.
Gé van Geldorp.
Hiya Lionel,
--- Lionel Ulmer <lionel.ulmer(a)free.fr> wrote:
> On Fri, Nov 07, 2003 at 10:32:02AM +0000, Mike Hearn wrote:
> > Lionel, could QEMU be used here? I guess the driver expects to have
> > kernel level access to the machine, so we could either:
>
> Well, as I have no idea how .SYS loading working and how it
> interfaces with
> the kernel, I cannot comment here.
>
> Note that a low level kernel presentation by ReactOS people would be
> a nice
> thing to have at Wineconf :-)
We will see what we can put together for wineconf =)
I have been following this thread for a while so I have to speak up
about the DMCA issues you guys have been discussing.
It is in the ReactOS Projects interest to have a working safedisk
driver also so we might be able to work together on something. There
has been work at loading Windows filesystem drivers using ReactOS in
the past so I dont see safedisk being that big of a deal.
http://www.jankratochvil.net/project/captive/
Copying the safedisk driver from Windows and loading it in ReactOS
should just work as we have the same design microsoft does. Adapting
that to work on Linux+ReactOS you would need to talk to Jan.
Still the better method is for us to write our own safedisk driver from
scratch but I am not sure that this wont violate the DMCA.
IMHO the WINE project should adopt the defence the xbox-linux and the
ReactOS projects have:
"Everything done on this project is for the sole purpose of writing
interoperable software under Sect. 1201 (f) Reverse Engineering
exception of the DMCA."
We will still have the legal battle to fight one day but I think you
will win if you reimplement safedisk and use this as your argument. One
day WINE, ReactOS and other project are going to get taken to court
over the DMCA. This is a given. The question is do you want it to be
over this? Is gamming support in WINE and ReactOS important enough to
you?
Thanks
Steven
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree