Menu
▾
▴
reactos-kernel
|
From: Eric K. <ek...@rz...> - 2002-07-07 13:19:40
|
"Steven Edwards" <ste...@ya...> wrote: > I would like it if it didnt do a GUI boot by default > and you just had to type "win" or something but thats > just me. I suggest a new kernel command line option '/NOGUI'. Just typing "win" to start the gui won't work because winlogon must always be the first gui app. Eric |
|
From: KJK::Hyperion <no...@li...> - 2002-07-07 17:51:25
|
At 15.19 07/07/2002, you wrote: > > I would like it if it didnt do a GUI boot by default > > and you just had to type "win" or something but thats > > just me. >I suggest a new kernel command line option '/NOGUI'. Just typing "win" to >start the gui won't work because winlogon must always be the first gui app. "must"? what forces us to? |
|
From: Robert K. <ro...@ko...> - 2002-07-08 14:21:09
|
What stays against a winlogon that lives in two worlds? If the GUI is already active, winlogon uses Windowing functions and else it uses the console API to gather USER and PW. Eric Kohl schrieb: >"Steven Edwards" <ste...@ya...> wrote: > > > > >>I would like it if it didnt do a GUI boot by default >>and you just had to type "win" or something but thats >>just me. >> >> > >I suggest a new kernel command line option '/NOGUI'. Just typing "win" to >start the gui won't work because winlogon must always be the first gui app. > >Eric > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >We have stuff for geeks like you. >http://thinkgeek.com/sf >_______________________________________________ >reactos-kernel mailing list >rea...@li... >https://lists.sourceforge.net/lists/listinfo/reactos-kernel > > |
|
From: Royce M. I. <ro...@ev...> - 2002-07-06 22:04:05
Attachments:
mingwenv.zip
|
Okay, I checked, and I have 0.0.0.19, which as far as I can tell is the latest kernel. CMD.EXE is compiled with __REACTOS__. Immediately upon booting ReactOS, here are the commands I issue: C:\ReactOS> bin\cmd [snip - cmd startup info] C:\ReactOS> c:\bat\mingwenv.bat C:\ReactOS> set dircmd=/ogne include=c:\mingw\include;%include% lib=c:\mingw\lib;%lib% OS=ReactOS PATH=c:\mingw\bin;%path% SystemDrive=C: reactos SystemRoot=C:\reactos windir=C:\reactos C:\ReactOS> I have attached the relevant batch files. Either there's a bug, or I'm going something wrong. Royce3 P.S. Why does "reactos" appear below "SystemDrive" in the "Set" list? |
|
From: Eric K. <ek...@rz...> - 2002-07-07 13:19:40
|
"Royce Mitchell III" <ro...@ev...> wrote: > Okay, I checked, and I have 0.0.0.19, which as far as I can tell is the > latest kernel. Could you try the current cvs modules 'reactos' and 'rosapps'? The 0.0.19 release is older than 130 days and we will release 0.0.20 soon. The usual time between releases is about 150 days. This means that 0.0.19 is _outdated_. Eric |
|
From: Royce M. I. <ro...@ev...> - 2002-07-07 23:00:07
Attachments:
Make.zip
|
I get a bunch of warnings about old commands... then... ntoskrnl.o(.text+0xb0d8):main.c: undefined reference to `LdrProcessDriver' ntoskrnl.o(.text+0x1efa7):close.c: undefined reference to `ObGetReferenceCount' ntoskrnl.o(.text+0x1f027):close.c: undefined reference to `ObGetReferenceCount' ntoskrnl.o(.text+0x2214e):arcname.c: undefined reference to `xHalQueryDriveLayout' ntoskrnl.o(.text+0x2e23a):kdebug.c: undefined reference to `KdPortInitializeEx@12' ntoskrnl.o(.text+0x2e25a):kdebug.c: undefined reference to `KdPortInitializeEx@12' ntoskrnl.o(.text+0x2e30b):kdebug.c: undefined reference to `KdPortPutByteEx@8' ntoskrnl.o(.text+0x2e322):kdebug.c: undefined reference to `KdPortPutByteEx@8' ntoskrnl.o(.text+0x2e5e6):kdebug.c: undefined reference to `KdPortPutByteEx@8' ntoskrnl.o(.text+0x2e605):kdebug.c: undefined reference to `KdPortGetByteEx@8' ntoskrnl.o(.text+0x2ffa1):gdbstub.c: undefined reference to `KdPortGetByteEx@8' I've attached the entire build output... |
|
From: Steven E. <ste...@ya...> - 2002-07-08 07:26:14
|
I always get the warnings about old commands also but I jsut did a full rebuild and am not getting the problems in ntoskrnl/hal you are seeing. Anyone else having this problem? David can you update and make clean to check and see if you get this problem as Royce is? I just did and its checking out fine. Thanks Steven --- Royce Mitchell III <ro...@ev...> wrote: > I get a bunch of warnings about old commands... > > then... > > ntoskrnl.o(.text+0xb0d8):main.c: undefined reference > to `LdrProcessDriver' > ntoskrnl.o(.text+0x1efa7):close.c: undefined > reference to __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
|
From: Royce M. I. <ro...@ev...> - 2002-07-08 07:58:24
|
Stupid me... I didn't think to do a make clean. Not used to using makefiles, yet. make clean failed, but I was able to fix it by copying RDEL.EXE to the C:\ReactOS directory. Should this have been necessary? Anyways, kicking off the rebuild from post-clean. Hopefully will work this time :) Royce3 ----- Original Message ----- From: "Steven Edwards" <ste...@ya...> To: <rea...@li...> Sent: Monday, July 08, 2002 2:26 AM Subject: Re: [ros-kernel] today's cvs - build errors > I always get the warnings about old commands also but > I jsut did a full rebuild and am not getting the > problems in ntoskrnl/hal you are seeing. Anyone else > having this problem? > > David can you update and make clean to check and see > if you get this problem as Royce is? I just did and > its checking out fine. > > Thanks > Steven > > --- Royce Mitchell III <ro...@ev...> wrote: > > I get a bunch of warnings about old commands... > > > > then... > > > > ntoskrnl.o(.text+0xb0d8):main.c: undefined reference > > to `LdrProcessDriver' > > ntoskrnl.o(.text+0x1efa7):close.c: undefined > > reference to > > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Oh, it's good to be a geek. > http://thinkgeek.com/sf > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel > |
|
From: Robert D. <od...@pn...> - 2002-07-08 12:33:44
|
> >make clean failed, but I was able to fix it by copying RDEL.EXE to the >C:\ReactOS directory. This is the quick fix I have used a couple of times since a while back. make clean actually uses rdel to delete rdel from the tools directory. This in itself works fine but make then tries to delete some more files. Having make clean the tools directory (and particularly the .exe's) as the very last step of 'make clean' should fix it properly. Robert. |
|
From: Steven E. <ste...@ya...> - 2002-07-08 12:37:13
|
your right I dont see why it trys to clean tools when it does. go ahead and patch it. > Having make clean the tools directory (and > particularly the .exe's) as > the very last step of 'make clean' should fix it > properly. > > Robert. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
|
From: Royce M. I. <ro...@ev...> - 2002-07-08 12:43:47
|
Went and checked the results this morning. It still failed after doing a make clean and then make again. Ah hah! I found the problem! Apparently we switched from using NASM.EXE to NASMW.EXE. I only had the nasm.exe in my mingw directory. Royce3 |
|
From: Robert D. <od...@pn...> - 2002-07-08 12:56:35
|
> >Ah hah! I found the problem! >Apparently we switched from using NASM.EXE to NASMW.EXE. I only had the >nasm.exe in my mingw directory. I have simply copied the file in the past when missing either one. Is their a difference between these two versions anything in ReactOS depends upon? Thanks, Robert. |
|
From: Steven E. <ste...@ya...> - 2002-07-08 12:58:19
|
> >Ah hah! I found the problem! > >Apparently we switched from using NASM.EXE to > NASMW.EXE. I only had the > >nasm.exe in my mingw directory. > > I have simply copied the file in the past when > missing either one. Is their a > difference between these two versions anything in > ReactOS depends upon? Thats what I have always done and never had a problem. Steven __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
|
From: Royce M. I. <ro...@ev...> - 2002-07-08 13:01:02
|
make was successful, but now make install is failing :) Almost there :) It looks like it's having a problem finding zlib. Here's the pertinent snippet: make -C drivers/lib/zlib install make[1]: *** No rule to make target `zlib.sym', needed by `../../../reactos/system32/zlib.a'. Stop. make[1]: Entering directory `C:/reactos/drivers/lib/zlib' make[1]: Leaving directory `C:/reactos/drivers/lib/zlib' C:\MINGW\BIN\MAKE.EXE: *** [zlib_install] Error 2 I can't troubleshoot this until I get home 'cause I'm already way late for work :) Will try this evening. Royce3 |
|
From: Eric K. <ek...@rz...> - 2002-07-06 17:24:37
|
"KJK::Hyperion" <no...@li...> wrote: > At 00.25 06/07/2002, you wrote: > > > Sorry, but I think the bug is in the ReactOS shell. It should > > > ExpandEnvironmentStrings() the command line > >The ReactOS shell (shell.exe) doesn't support environment variables at all. > >The problem was that the expansion of environment variables works on > >Windows when cmd is used. Although cmd doesn't call > >ExpandEnvironmentStrings(). SetEnvironmentVariable() expands environment > >variables but ReactOS didn't implement that. > > has this been verified? because here (Windows 2000 Professional) I'm able > to set a variable to "%PATH%" without it being expanded: > > ALDEBARAN\Hyperion [D:\home\Hyperion] > ::set DOH=^%PATH^% > > ALDEBARAN\Hyperion [D:\home\Hyperion] > ::echo %DOH% > %PATH% > Hyperion, you're absolutely right! Cmd expands envionment variables internally as part of the commandline analysis. Neither the ntdll functions nor the kernel32 functions expand environment variables automatically. I'll revert the patch! Eric |
|
From: Eric K. <ek...@rz...> - 2002-07-05 00:10:43
|
"Royce Mitchell III" <ro...@ev...> wrote: Hello Royce! > So, I'm thinking I could start by adding support for that. I've already > found the function I need to change in NTDLL.DLL > (RtlSetEnvironmentVariable), and I've pasted it into a test app so I can > modify, and test it without rebooting frequently. Did you test RtlSetEnvironmentVariable() for the ability to expand a variable? Im not sure whether the expansion is done by RtlSetEnvironmentVariable() or by SetEnvironmentVariable[A/W] (in lib/kernel32/misc/env.c). > Unless somebody's already working on that, I'll do it. I remember this bug was reported about a year ago. Please, go ahead and fix it! > Then, as you suggested, I'm going to start "hacking". I can't run Norton > Commander, yet, and I'd like to get that working. I also noticed that EDIT > and MC don't work, either. Personally I feel it would be critical that the > command prompt work well :) Sure! Regards, Eric Kohl |
|
From: Royce M. I. <ro...@ev...> - 2002-07-05 00:23:10
|
I'll look into that in a little bit. How do I make a diff? I've never done it before. ----- Original Message ----- From: "Eric Kohl" <ek...@rz...> To: "ReactOS Kernel" <rea...@li...> Sent: Thursday, July 04, 2002 7:05 PM Subject: Re: [ros-kernel] compiling > > "Royce Mitchell III" <ro...@ev...> wrote: > > Hello Royce! > > > So, I'm thinking I could start by adding support for that. I've already > > found the function I need to change in NTDLL.DLL > > (RtlSetEnvironmentVariable), and I've pasted it into a test app so I can > > modify, and test it without rebooting frequently. > > Did you test RtlSetEnvironmentVariable() for the ability to expand a > variable? > Im not sure whether the expansion is done by RtlSetEnvironmentVariable() or > by SetEnvironmentVariable[A/W] (in lib/kernel32/misc/env.c). > > > > Unless somebody's already working on that, I'll do it. > > I remember this bug was reported about a year ago. Please, go ahead and fix > it! > > > Then, as you suggested, I'm going to start "hacking". I can't run Norton > > Commander, yet, and I'd like to get that working. I also noticed that EDIT > > and MC don't work, either. Personally I feel it would be critical that the > > command prompt work well :) > > Sure! > > > Regards, > Eric Kohl > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Caffeinated soap. No kidding. > http://thinkgeek.com/sf > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel > |
|
From: James M. <jid...@sa...> - 2002-07-05 01:08:14
|
If you have mingw installed is to copy the old file(s) with some prefix added or house all modified file in a different directory. Then just issue "diff -u <path to original> <path to new>". This is how I do it. Someone my have a better way. James Marjie GnuPG KeyID: 0x7C837497 "Take your life in your own hands, and what happens? A terrible thing: no one to blame." -Erica Jong |
|
From: Royce M. I. <ro...@ev...> - 2002-07-05 01:16:35
|
I get a bad command on diff. Is it supposed to come with mingw? ----- Original Message ----- From: "James Marjie" <jid...@sa...> To: <rea...@li...> Sent: Thursday, July 04, 2002 8:06 PM Subject: Re: [ros-kernel] compiling > If you have mingw installed is to copy the old file(s) with some prefix > added or house all modified file in a different directory. Then just issue > "diff -u <path to original> <path to new>". > This is how I do it. Someone my have a better way. > > James Marjie > GnuPG KeyID: 0x7C837497 > > "Take your life in your own hands, and what happens? A terrible thing: no > one to blame." -Erica Jong > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Caffeinated soap. No kidding. > http://thinkgeek.com/sf > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel > |
|
From: James M. <jid...@sa...> - 2002-07-05 04:14:33
|
I thought so. Guess I was wrong. 8^) James Marjie GnuPG KeyID: 0x7C837497 "Take your life in your own hands, and what happens? A terrible thing: no one to blame." -Erica Jong |
|
From: Royce M. I. <ro...@ev...> - 2002-07-05 01:24:03
Attachments:
env.diff
|
Finally found a diff.exe! ( It was hiding in my WinCVS directory ). I got dynamic buffer allocation working, and I also fixed some indentation inconsistency. |
|
From: Eric K. <ek...@rz...> - 2002-07-05 15:21:03
|
"Royce Mitchell III" <ro...@ev...> wrote: > Finally found a diff.exe! ( It was hiding in my WinCVS directory ). > > I got dynamic buffer allocation working, and I also fixed some indentation > inconsistency. You can use diff directly from the WinCVS console. The console supports several unix-like command, like cd and pwd. You can use them to navigate the cvs tree, but make sure you use the slash instead of the backslash. To create a patch against the current cvs version you have to change to the desired directory and type 'cvs -z3 diff -u env.c >env.diff'. I'll test your attached patch and commit it. Thanks, Eric |
|
From: James M. <jid...@sa...> - 2002-07-05 19:36:06
|
Thanks for that information on making diff the right way for ReactOS. James Marjie GnuPG KeyID: 0x7C837497 "Take your life in your own hands, and what happens? A terrible thing: no one to blame." -Erica Jong |
|
From: Royce M. I. <ro...@ev...> - 2002-07-05 00:10:50
Attachments:
env.c
|
Okay, I couldn't get dynamic allocation to work, so I'm not sure how I'm supposed to do that. In the mean time, here's a fix using a static buffer. This file goes in reactos/lib/ntdll/rtl. Now, statements like SET PATH=C:\Blah;%PATH% will work. |
|
From: Eric K. <ek...@rz...> - 2002-07-05 22:20:54
|
"KJK::Hyperion" <no...@li...> wrote: > Sorry, but I think the bug is in the ReactOS shell. It should > ExpandEnvironmentStrings() the command line The ReactOS shell (shell.exe) doesn't support environment variables at all. The problem was that the expansion of environment variables works on Windows when cmd is used. Although cmd doesn't call ExpandEnvironmentStrings(). SetEnvironmentVariable() expands environment variables but ReactOS didn't implement that. Eric |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X