Menu
▾
▴
reactos-kernel
|
From: Royce M. I. <ro...@ev...> - 2002-07-04 00:11:08
|
Hi, I heard about your project recently through a member in the wxWindows = group. I'm tied up in a contribution to that project at the moment, but then = I'd like to start helping out with your project as well. Anyhoo, I have ReactOS installed on my computer, and up and running, though I'm finding many many things not working ( I'm sure you know... = ). I have gone through the helps files on the web site, and I still have = just a couple questions before I get started... 1) What is the recommended compiler for recompiling the OS? ( Can I = recompile from within the OS, yet? ) 2) I noticed references to WINE in the dev list. Where should I obtain = the version of WINE you've been using? ( I.E. do you have a fork, or are you using = the main distro? ) 3) I know you've approached Calmira about using their explorer = replacement. Unfortunately it is a 16-bit delphi app. Is anybody working on a 32-bit = one, and if not, do you think you're ready for me to start developing one for = you? 4) Any other advise you can give me? I've become very appalled at MS's = actions lately, and I'm not particularly happy with the Linux solution for a = workstation, so I'd really like to see ReactOS take off! Royce3 |
|
From: Steven E. <ste...@ya...> - 2002-07-04 01:15:04
|
> 1) What is the recommended compiler for recompiling > the OS? ( Can I recompile > from within the OS, yet? ) You can use mingw/gcc in ReactOS however it is VERY slow due to IO issues in the filesystem drivers. Hartmut has been working on this > 2) I noticed references to WINE in the dev list. > Where should I obtain the version > of WINE you've been using? ( I.E. do you have a > fork, or are you using the main > distro? ) We have a fork that is out of date....I have been working with the main winehq tree to bring our stuff in sync although it is not ready for prime time and we still lack windowing so it doesnt much matter. If you want to play with it you will need mingw+msys+ the MSYS-DTK and configure it like this ./configure CFLAGS="-D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK" CCFLAGS="-D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK" make depend make tools then you will need to try and build the dlls you need. > 3) I know you've approached Calmira about using > their explorer replacement. > Unfortunately it is a 16-bit delphi app. Is anybody > working on a 32-bit one, > and if not, do you think you're ready for me to > start developing one for you? Not currently and I for adapting lightstep to suite our needs. > 4) Any other advise you can give me? I've become > very appalled at MS's actions > lately, and I'm not particularly happy with the > Linux solution for a workstation, > so I'd really like to see ReactOS take off! Anything you are interested in please take a look at. Every little bit helps Thanks 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-04 01:29:36
|
> > 1) What is the recommended compiler for recompiling > > the OS? ( Can I recompile > > from within the OS, yet? ) > > You can use mingw/gcc in ReactOS however it is VERY > slow due to IO issues in the filesystem drivers. > Hartmut has been working on this > Thanks for the quick reply! Just out of curiosity, is the performance issue due to a lack of a "smartdrv.exe" Royce3 |
|
From: KJK::Hyperion <no...@li...> - 2002-07-04 18:23:19
|
At 03.25 04/07/2002, you wrote: > > > 1) What is the recommended compiler for recompiling > > > the OS? ( Can I recompile > > > from within the OS, yet? ) > > You can use mingw/gcc in ReactOS however it is VERY > > slow due to IO issues in the filesystem drivers. > > Hartmut has been working on this >Thanks for the quick reply! >Just out of curiosity, is the performance issue due to a lack of a >"smartdrv.exe" nope. DOS "dies" an instant before ReactOS starts. It's ReactOS that doesn't do buffered I/O, and the compiler/linker that write files in really small chunks (a handful bytes at a time) |
|
From: Royce M. I. <ro...@ev...> - 2002-07-04 22:33:38
|
I know that DOS dies... That's the same thing loadlin does, and I've read about booting OS's in the past ( though I'm by no means an expert ) So, I'm sorry if I caused confusion, but my question was: Is the I/O performance problem because there is no hard-disk cacheing available in reactos, yet? ----- Original Message ----- From: "KJK::Hyperion" <no...@li...> To: <rea...@li...> Sent: Thursday, July 04, 2002 12:33 PM Subject: Re: [ros-kernel] compiling > At 03.25 04/07/2002, you wrote: > > > > 1) What is the recommended compiler for recompiling > > > > the OS? ( Can I recompile > > > > from within the OS, yet? ) > > > You can use mingw/gcc in ReactOS however it is VERY > > > slow due to IO issues in the filesystem drivers. > > > Hartmut has been working on this > >Thanks for the quick reply! > >Just out of curiosity, is the performance issue due to a lack of a > >"smartdrv.exe" > > nope. DOS "dies" an instant before ReactOS starts. It's ReactOS that > doesn't do buffered I/O, and the compiler/linker that write files in really > small chunks (a handful bytes at a time) > > > > ------------------------------------------------------- > 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: Eric K. <ek...@rz...> - 2002-07-05 15:21:03
|
"Steven Edwards" <ste...@ya...> wrote: > > 1) What is the recommended compiler for recompiling > > the OS? ( Can I recompile > > from within the OS, yet? ) > > You can use mingw/gcc in ReactOS however it is VERY > slow due to IO issues in the filesystem drivers. > Hartmut has been working on this There are some reasons for the low I/O performance: - no fast io support in ntoskrnl and fsd's - adapi.sys supports PIO mode but no busmaster dma yet - perhaps no or bad lazy write support in the cache manager (I don't know about this one) Eric |
|
From: Casper H. <ch...@us...> - 2002-07-06 02:26:13
|
fre, 2002-07-05 kl. 16:45 skrev Eric Kohl: > > "Steven Edwards" <ste...@ya...> wrote: ... > - perhaps no or bad lazy write support in the cache manager (I don't know > about this one) > > Eric Currently, no lazy writing is done. Casper |
|
From: Danny S. <dan...@cl...> - 2002-08-31 05:01:05
|
Just a heads up that the latest mingw release of binutils (binutils-2.13-20020808-1) is broken for __fastcall when building dlls using gcc -shared. Some of Eric's patches got missed out while juggling and testing different patchsets. One day. hopefully, the fastcall will be part of official sources so this problem won't arise. Anyway, I'm preparing a fixed release now. Danny |
|
From: Jason F. <jas...@ya...> - 2002-07-04 05:57:13
|
--- Royce Mitchell III <ro...@ev...> wrote: >1) What is the recommended compiler for recompiling the OS? ( Can I >recompile from within the OS, yet? ) On reactos.com, go to the Software section for more info on the recommended compiler and download links. >4) Any other advise you can give me? I've become very appalled at >MS's actions lately, and I'm not particularly happy with the Linux >solution for a workstation, so I'd really like to see ReactOS take off! If you haven't already done so, check out the tutorials under the Documents section of reactos.com - Jason __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
|
From: KJK::Hyperion <no...@li...> - 2002-07-04 18:23:17
|
At 02.06 04/07/2002, you wrote: >1) What is the recommended compiler for recompiling the OS? Only one compiler can: the special version of GCC 2.9.5 for Windows you can download from our home page >( Can I recompile from within the OS, yet? ) AFAIK, ReactOS isn't self-hosted yet >2) I noticed references to WINE in the dev list. Where should I obtain the >version of WINE you've been using? ( I.E. do you have a fork, or are you >using the main distro? ) A fork, at the moment. It's in the CVS tree, "wine" module. But you don't need it to compile the base system >3) I know you've approached Calmira about using their explorer >replacement. Unfortunately it is a 16-bit delphi app. Is anybody working >on a 32-bit one, and if not, do you think you're ready for me to start >developing one for you? Personally, I'd invest time only on a Windows Shell replacement (shell32 + shlwapi). Any time invested elsewhere is wasted time, IMHO. Our minimal graphical shell of choice, LiteStep, needs it, and a ton of third party apps as well >4) Any other advise you can give me? Start hacking. If you're interested in user-mode system components, look at the source code of the base Win32 libraries and the (largely incomplete) sources for POSIX+, to see how Win32 and POSIX APIs map to NT APIs. If you're interested in win32 programming, you can start right away: develop for Windows, ReactOS will eventually be able to run it. If you want to help with the kernel or device drivers, there's a long way ahead :-) I suggest you start with a book on the topic >I've become very appalled at MS's actions lately, and I'm not particularly >happy with the Linux solution for a workstation, so I'd really like to see >ReactOS take off! same feelings here :-) |
|
From: Royce M. I. <ro...@ev...> - 2002-07-04 22:40:21
|
I've been looking around a little bit, and playing with it, and I'm finding a lot of stuff missing. For example, I have a batch file that sets up my MinGW environment. I tried to run it, and my PATH environment variable came out like this: PATH=C:\MinGW\Bin;%PATH% My include and lib variables are similarly broken. 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. Unless somebody's already working on that, I'll do 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 :) ----- Original Message ----- > > Personally, I'd invest time only on a Windows Shell replacement (shell32 + > shlwapi). Any time invested elsewhere is wasted time, IMHO. Our minimal > graphical shell of choice, LiteStep, needs it, and a ton of third party > apps as well |
|
From: Royce M. I. <ro...@ev...> - 2002-07-04 23:41:44
|
I've fixed RtlSetEnvironmentVariable, but at the moment the fix is using a static buffer. Can I safely call palloc from that function? Once I get that straightened out, I'll pass it on. I have also discovered a bug in RtlExpandEnvironmentStrings_U in the process. Royce3 ----- Original Message ----- From: "Royce Mitchell III" <ro...@ev...> To: <rea...@li...> Sent: Thursday, July 04, 2002 5:35 PM Subject: Re: [ros-kernel] compiling > I've been looking around a little bit, and playing with it, and I'm finding > a lot of stuff missing. > > For example, I have a batch file that sets up my MinGW environment. I tried > to run it, and my PATH environment variable came out like this: > > PATH=C:\MinGW\Bin;%PATH% > > My include and lib variables are similarly broken. > > 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. > > Unless somebody's already working on that, I'll do 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 :) > > ----- Original Message ----- > > > Personally, I'd invest time only on a Windows Shell replacement (shell32 + > > shlwapi). Any time invested elsewhere is wasted time, IMHO. Our minimal > > graphical shell of choice, LiteStep, needs it, and a ton of third party > > apps as well > > > > > ------------------------------------------------------- > 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: Eric K. <ek...@rz...> - 2002-07-05 00:10:43
|
"Royce Mitchell III" <ro...@ev...> wrote: > I've fixed RtlSetEnvironmentVariable, but at the moment the fix is using a > static buffer. Can I safely call palloc from that function? Once I get that > straightened out, I'll pass it on. You should use RtlAllocateHeap(RtlGetProcessHeap(), 0, <BufferSize>) to allocate a buffer in ntdll.dll. C-runtime heap functions like malloc(), calloc(), free(), etc. are *not* available in ntdll.dll. > I have also discovered a bug in RtlExpandEnvironmentStrings_U in the > process. Great! Can you send me the patch (unified diff format preferred)? I'll apply it to the cvs tree. Thanks, Eric Kohl |
|
From: KJK::Hyperion <no...@li...> - 2002-07-05 22:03:31
|
At 02.06 05/07/2002, you wrote: [...] >Now, statements like SET PATH=C:\Blah;%PATH% will work. Sorry, but I think the bug is in the ReactOS shell. It should ExpandEnvironmentStrings() the command line |
|
From: KJK::Hyperion <no...@li...> - 2002-07-05 23:50:25
|
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%
I've written a proof-of-concept in Delphi:
(************************************************************)
program envtest;
{$APPTYPE CONSOLE}
uses
Windows
;
var
env: PChar;
begin
(* set a variable to a value containing a reference to another
variable *)
SetEnvironmentVariable('DOH', '%PATH%');
(* get a pointer to the environment *)
env:= GetEnvironmentStrings();
(* repeat until the environment is empty *)
while env^ <> #0 do begin
(* print the current variable *)
WriteLn(String(env));
(* skip until the null terminator *)
repeat Inc(env); until env^ = #0;
(* skip the null terminator *)
Inc(env);
end;
end.
(************************************************************)
It outputs:
=::=::\
ALLUSERSPROFILE=D:\home\shared
APPDATA=D:\home\Hyperion\Dati applicazioni
BASEDIR=D:\devtools\ntddk
BCCDIR=D:\devtools\bcc
CLASSPATH=D:\programmi\sviluppo\sdk\Java\jre\lib;D:\programmi\sviluppo\sdk\Java\lib;.;"D:\Programmi\JavaSoft\JRE\1.3\lib\ext\QTJava.zip"
CommonProgramFiles=D:\Programmi\File comuni
COMPUTERNAME=ALDEBARAN
ComSpec=D:\WINNT\system32\cmd.exe
DDKDRIVE=D:
DOH=%PATH% [<--- ]
[and more]
It looks like SetEnvironmentVariable doesn't parse the variable's value in
any way (except scanning for the null terminator, of course). Maybe
RtlSetEnvironmentVariable does? Let's see:
(************************************************************)
program envtest2;
{$APPTYPE CONSOLE}
type
NTSTATUS = Cardinal;
BOOLEAN = LongBool;
PWSTR = PWideChar;
USHORT = Word;
UNICODE_STRING = record
Length, MaximumLength: USHORT;
Buffer: PWSTR;
end;
procedure RtlInitUnicodeString(
var DestinationString: UNICODE_STRING;
const SourceString: PWSTR
); stdcall; external 'ntdll.dll';
function RtlCreateEnvironment(
Inherit: BOOLEAN;
var Environment: PWSTR
): NTSTATUS; stdcall; external 'ntdll.dll';
procedure RtlDestroyEnvironment(
Environment: PWSTR
); stdcall; external 'ntdll.dll';
function RtlSetEnvironmentVariable (
var Environment: PWSTR;
var Name, Value: UNICODE_STRING
): NTSTATUS; stdcall; external 'ntdll.dll';
var
environ, envtail: PWSTR;
dohName, dohValue: UNICODE_STRING;
begin
(* copy the environment *)
RtlCreateEnvironment(True, environ);
RtlInitUnicodeString(dohName, 'DOH');
RtlInitUnicodeString(dohValue, '%PATH%');
(* set DOH="%PATH%" *)
RtlSetEnvironmentVariable(environ, dohName, dohValue);
envtail:= environ;
(* repeat until the environment is empty *)
while envtail^ <> #0 do begin
(* write the current variable *)
WriteLn(String(envtail));
(* skip until the null terminator *)
repeat Inc(envtail) until envtail^ = #0;
(* skip the null terminator *)
Inc(envtail);
end;
(* destroy the copy of the environment *)
RtlDestroyEnvironment(environ);
end.
(************************************************************)
and here's the output:
=::=::\
ALLUSERSPROFILE=D:\home\shared
APPDATA=D:\home\Hyperion\Dati applicazioni
BASEDIR=D:\devtools\ntddk
BCCDIR=D:\devtools\bcc
CLASSPATH=D:\programmi\sviluppo\sdk\Java\jre\lib;D:\programmi\sviluppo\sdk\Java\lib;.;"D:\Programmi\JavaSoft\JRE\1.3\lib\ext\QTJava.zip"
CommonProgramFiles=D:\Programmi\File comuni
COMPUTERNAME=ALDEBARAN
ComSpec=D:\WINNT\system32\cmd.exe
DDKDRIVE=D:
DOH=%PATH% [<--- ]
[and more]
Nope. Windows doesn't expand variable references, unless explicitely asked
for. ReactOS shouldn't either
|
|
From: Royce M. I. <ro...@ev...> - 2002-07-06 04:41:11
|
Well..
If cmd.exe properly expands under NT, but not under ReactOS, then where's
the bug? I'll be glad to apply the fix where it needs to be.
Royce3
----- Original Message -----
From: "KJK::Hyperion" <no...@li...>
To: <rea...@li...>
Sent: Friday, July 05, 2002 6:52 PM
Subject: Re: [ros-kernel] bugfix
> 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%
>
> I've written a proof-of-concept in Delphi:
>
> (************************************************************)
> program envtest;
> {$APPTYPE CONSOLE}
>
> uses
> Windows
> ;
>
> var
> env: PChar;
>
> begin
> (* set a variable to a value containing a reference to another
> variable *)
> SetEnvironmentVariable('DOH', '%PATH%');
>
> (* get a pointer to the environment *)
> env:= GetEnvironmentStrings();
>
> (* repeat until the environment is empty *)
> while env^ <> #0 do begin
> (* print the current variable *)
> WriteLn(String(env));
>
> (* skip until the null terminator *)
> repeat Inc(env); until env^ = #0;
>
> (* skip the null terminator *)
> Inc(env);
> end;
>
> end.
> (************************************************************)
>
> It outputs:
>
> =::=::\
> ALLUSERSPROFILE=D:\home\shared
> APPDATA=D:\home\Hyperion\Dati applicazioni
> BASEDIR=D:\devtools\ntddk
> BCCDIR=D:\devtools\bcc
>
CLASSPATH=D:\programmi\sviluppo\sdk\Java\jre\lib;D:\programmi\sviluppo\sdk\J
ava\lib;.;"D:\Programmi\JavaSoft\JRE\1.3\lib\ext\QTJava.zip"
> CommonProgramFiles=D:\Programmi\File comuni
> COMPUTERNAME=ALDEBARAN
> ComSpec=D:\WINNT\system32\cmd.exe
> DDKDRIVE=D:
> DOH=%PATH% [<--- ]
> [and more]
>
> It looks like SetEnvironmentVariable doesn't parse the variable's value in
> any way (except scanning for the null terminator, of course). Maybe
> RtlSetEnvironmentVariable does? Let's see:
>
> (************************************************************)
> program envtest2;
> {$APPTYPE CONSOLE}
>
> type
> NTSTATUS = Cardinal;
> BOOLEAN = LongBool;
> PWSTR = PWideChar;
> USHORT = Word;
>
> UNICODE_STRING = record
> Length, MaximumLength: USHORT;
> Buffer: PWSTR;
> end;
>
> procedure RtlInitUnicodeString(
> var DestinationString: UNICODE_STRING;
> const SourceString: PWSTR
> ); stdcall; external 'ntdll.dll';
>
> function RtlCreateEnvironment(
> Inherit: BOOLEAN;
> var Environment: PWSTR
> ): NTSTATUS; stdcall; external 'ntdll.dll';
>
> procedure RtlDestroyEnvironment(
> Environment: PWSTR
> ); stdcall; external 'ntdll.dll';
>
> function RtlSetEnvironmentVariable (
> var Environment: PWSTR;
> var Name, Value: UNICODE_STRING
> ): NTSTATUS; stdcall; external 'ntdll.dll';
>
> var
> environ, envtail: PWSTR;
> dohName, dohValue: UNICODE_STRING;
>
> begin
> (* copy the environment *)
> RtlCreateEnvironment(True, environ);
>
> RtlInitUnicodeString(dohName, 'DOH');
> RtlInitUnicodeString(dohValue, '%PATH%');
>
> (* set DOH="%PATH%" *)
> RtlSetEnvironmentVariable(environ, dohName, dohValue);
>
> envtail:= environ;
>
> (* repeat until the environment is empty *)
> while envtail^ <> #0 do begin
> (* write the current variable *)
> WriteLn(String(envtail));
>
> (* skip until the null terminator *)
> repeat Inc(envtail) until envtail^ = #0;
>
> (* skip the null terminator *)
> Inc(envtail);
> end;
>
> (* destroy the copy of the environment *)
> RtlDestroyEnvironment(environ);
>
> end.
> (************************************************************)
>
> and here's the output:
>
> =::=::\
> ALLUSERSPROFILE=D:\home\shared
> APPDATA=D:\home\Hyperion\Dati applicazioni
> BASEDIR=D:\devtools\ntddk
> BCCDIR=D:\devtools\bcc
>
CLASSPATH=D:\programmi\sviluppo\sdk\Java\jre\lib;D:\programmi\sviluppo\sdk\J
ava\lib;.;"D:\Programmi\JavaSoft\JRE\1.3\lib\ext\QTJava.zip"
> CommonProgramFiles=D:\Programmi\File comuni
> COMPUTERNAME=ALDEBARAN
> ComSpec=D:\WINNT\system32\cmd.exe
> DDKDRIVE=D:
> DOH=%PATH% [<--- ]
> [and more]
>
> Nope. Windows doesn't expand variable references, unless explicitely asked
> for. ReactOS shouldn't either
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Bringing you mounds of caffeinated joy.
> http://thinkgeek.com/sf
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel
>
|
|
From: Eric K. <ek...@rz...> - 2002-07-06 17:24:37
|
"Royce Mitchell III" <ro...@ev...> wrote: > If cmd.exe properly expands under NT, but not under ReactOS, then where's > the bug? I'll be glad to apply the fix where it needs to be. Actually, there is no bug in ReactOS. After reverting your patch, cmd expands environment variables under ReactOS too. There are a few related bugs in cmd: 1) It does not handle environment varables in a water-proof way. Environment variables that are larger than 511 characters will not be expanded properly. 2) The command line buffers are still allocated from the stack. Eric |
|
From: KJK::Hyperion <no...@li...> - 2002-07-06 16:34:24
|
At 11.15 06/07/2002, you wrote: >Yes, I verified it on Win98SE, WinNT4(SP6a) and Win2K Pro(SP2). On all >OS's an environment variable is expanded when using the default shell >(command.com/cmd.exe) or ReactOS cmd.exe! but our cmd.exe doesn't run on ReactOS (AFAIK). The problem is in the obsolete shell.exe. And if you look at our cmd.exe's sources, you'll see that it expands environment variables as part of the parsing > > ALDEBARAN\Hyperion [D:\home\Hyperion] > > ::set DOH=^%PATH^% >Why do you use '^%' instead of '%'? "^" is the escape character. I want DOH to be assigned the literal string "%PATH%", to show that Win32 won't expand it |
|
From: Eric K. <ek...@rz...> - 2002-07-06 17:29:28
|
"KJK::Hyperion" <no...@li...> wrote: > but our cmd.exe doesn't run on ReactOS (AFAIK). The problem is in the > obsolete shell.exe. And if you look at our cmd.exe's sources, you'll see > that it expands environment variables as part of the parsing Cmd runs on ReactOS. But you have to make sure you build the ReactOS-compatible version, which doesn't use unimplemented features. ;-) You'll have to uncomment the line '#define __REACTOS__' in the config.h file. This version of cmd runs on ReactOS and expands environment varables, in most cases, properly. Eric |
|
From: Royce M. I. <ro...@ev...> - 2002-07-06 20:35:55
|
Does this mean that to fix the problem I need to get the latest source? What are the CVS commands? I don't remember ever seeing them on the web site. ----- Original Message ----- From: "Eric Kohl" <ek...@rz...> To: <rea...@li...> Sent: Saturday, July 06, 2002 12:33 PM Subject: Re: [ros-kernel] bugfix > > "KJK::Hyperion" <no...@li...> wrote: > > > but our cmd.exe doesn't run on ReactOS (AFAIK). The problem is in the > > obsolete shell.exe. And if you look at our cmd.exe's sources, you'll see > > that it expands environment variables as part of the parsing > > Cmd runs on ReactOS. But you have to make sure you build the > ReactOS-compatible version, which doesn't use unimplemented features. ;-) > You'll have to uncomment the line '#define __REACTOS__' in the config.h > file. This version of cmd runs on ReactOS and expands environment varables, > in most cases, properly. > > Eric > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Got root? We do. > http://thinkgeek.com/sf > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel > |
|
From: Kohn E. D. <em...@cs...> - 2002-07-06 21:03:27
|
On Sat, 6 Jul 2002, Royce Mitchell III wrote: > Does this mean that to fix the problem I need to get the latest source? > > What are the CVS commands? I don't remember ever seeing them on the web > site. Look at the developer tutorials at http://reactos.com/rosdocs/tutorials/bk02.html chapters 10 and 11. Emil > > ----- Original Message ----- > From: "Eric Kohl" <ek...@rz...> > To: <rea...@li...> > Sent: Saturday, July 06, 2002 12:33 PM > Subject: Re: [ros-kernel] bugfix > > > > > > "KJK::Hyperion" <no...@li...> wrote: > > > > > but our cmd.exe doesn't run on ReactOS (AFAIK). The problem is in the > > > obsolete shell.exe. And if you look at our cmd.exe's sources, you'll see > > > that it expands environment variables as part of the parsing > > > > Cmd runs on ReactOS. But you have to make sure you build the > > ReactOS-compatible version, which doesn't use unimplemented features. ;-) > > You'll have to uncomment the line '#define __REACTOS__' in the config.h > > file. This version of cmd runs on ReactOS and expands environment > varables, > > in most cases, properly. > > > > Eric > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Got root? We do. > > http://thinkgeek.com/sf > > _______________________________________________ > > reactos-kernel mailing list > > rea...@li... > > https://lists.sourceforge.net/lists/listinfo/reactos-kernel > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Got root? We do. > http://thinkgeek.com/sf > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel > |
|
From: Jason F. <jas...@ya...> - 2002-07-06 21:04:43
|
reactos.com > documents > tutorials > developer tutorials > sharing code - Jason --- Royce Mitchell III <ro...@ev...> wrote: > Does this mean that to fix the problem I need to get the latest > source? > > What are the CVS commands? I don't remember ever seeing them on the > web > site. > > ----- Original Message ----- > From: "Eric Kohl" <ek...@rz...> > To: <rea...@li...> > Sent: Saturday, July 06, 2002 12:33 PM > Subject: Re: [ros-kernel] bugfix > > > > > > "KJK::Hyperion" <no...@li...> wrote: > > > > > but our cmd.exe doesn't run on ReactOS (AFAIK). The problem is > in the > > > obsolete shell.exe. And if you look at our cmd.exe's sources, > you'll see > > > that it expands environment variables as part of the parsing > > > > Cmd runs on ReactOS. But you have to make sure you build the > > ReactOS-compatible version, which doesn't use unimplemented > features. ;-) > > You'll have to uncomment the line '#define __REACTOS__' in the > config.h > > file. This version of cmd runs on ReactOS and expands environment > varables, > > in most cases, properly. > > > > Eric > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Got root? We do. > > http://thinkgeek.com/sf > > _______________________________________________ > > reactos-kernel mailing list > > rea...@li... > > https://lists.sourceforge.net/lists/listinfo/reactos-kernel > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Got root? We do. > http://thinkgeek.com/sf > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
|
From: Steven E. <ste...@ya...> - 2002-07-06 21:54:08
|
Can we make cmd.exe a defualt option? I was thinking about adding a check in winlogon so that if it found %SystemRoot%\system32\cmd.exe it used it and if not then would load shell.exe. I guess it doesnt much matter as everything will change anyway, once we have windowing. Steven > Cmd runs on ReactOS. But you have to make sure you > build the > ReactOS-compatible version, which doesn't use > unimplemented features. ;-) > You'll have to uncomment the line '#define > __REACTOS__' in the config.h > file. This version of cmd runs on ReactOS and > expands environment varables, > in most cases, properly. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
|
From: Royce M. I. <ro...@ev...> - 2002-07-06 22:02:54
|
If I can make a request. I realize the goal is a windows NT clone, but is there no reason to add benefitial features? I'd really like to be able to at least turn on the option to not boot the GUI... Royce3 ----- Original Message ----- From: "Steven Edwards" <ste...@ya...> To: <rea...@li...> Sent: Saturday, July 06, 2002 4:54 PM Subject: Re: [ros-kernel] bugfix > Can we make cmd.exe a defualt option? I was thinking > about adding a check in winlogon so that if it found > %SystemRoot%\system32\cmd.exe it used it and if not > then would load shell.exe. I guess it doesnt much > matter as everything will change anyway, once we have > windowing. > > Steven > > > > Cmd runs on ReactOS. But you have to make sure you > > build the > > ReactOS-compatible version, which doesn't use > > unimplemented features. ;-) > > You'll have to uncomment the line '#define > > __REACTOS__' in the config.h > > file. This version of cmd runs on ReactOS and > > expands environment varables, > > in most cases, properly. > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Got root? We do. > http://thinkgeek.com/sf > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel > |
|
From: Steven E. <ste...@ya...> - 2002-07-06 22:09:58
|
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. --- Royce Mitchell III <ro...@ev...> wrote: > If I can make a request. I realize the goal is a > windows NT > clone, but is there no reason to add benefitial > features? > > I'd really like to be able to at least turn on the > option to > not boot the GUI... __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
×
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