Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.msdos.programmer > #4058
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Newsgroups | comp.os.msdos.programmer |
| Subject | Re: Booting process 0: how to find out its full path? |
| Date | 2021-11-16 20:46 +0100 |
| Organization | . . . |
| Message-ID | <20211116204601.0eabe49c@mateusz> (permalink) |
| References | <20211116104416.2b3d207f@mateusz> <XnsADE464DA8276Bauricauricauricauric@144.76.35.252> <20211116180721.434ef838@mateusz> <XnsADE478512A181auricauricauricauric@144.76.35.252> |
2021-11-16 at 18:49 -0000, Auric__ wrote: > The MS-DOS 2.0 source code is on Github, where you might look into > the file SYSINIT.ASM, available here: > > https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/SYSINIT.ASM Actually I did glance at the MS-DOS 2.0 code already, and my understanding is that they didn't even try addressing this, just relied on COMSPEC (if defined, either through SET or by feeding it as an argument to command.com), and if no COMSPEC then using the default location. That sounds okay when it's MS that does it, because it's their OS, but an alternative shell does not have this luxury. > HACK: when 4DOS.COM is the shell and it doesn't have an environment > from which to obtain its original program name, it grovels through > all of memory to find the filename that was used to exec it; it > wants to find the SHELL= line in the in-memory copy of CONFIG.SYS, > and it knows that sysinit converts the SHELL= keyword to an 'S', so > it expects to find an 'S' immediately before the filename, but since > we are now storing line # info in the config.sys memory image, 4DOS > fails to find the 'S' in the right spot. > So, on the final pass of CONFIG.SYS, copy the command code (eg, 'S') > over the line number info, since we no longer need that info anyway. > This relies on the fact that getchr leaves ES:SI pointing to the > last byte retrieved. That is very interesting indeed, thanks for sharing! This at least confirms that there is no "clean" way to do what I wanted... So I will probably give up on that. MS compatibility was only a bonus, my primary target is working with the DOS-C kernel, and there I do not have any such problems. Nonetheless, thank you for your kind research. > As for other flavors of DOS, most of them are open source, so I think > it would be worth it to download some source code and search for > "shell". Under DOS-C it is a no-brainer: the kernel actually allocates a tiny (96 bytes) environment and passes it to COMMAND.COM. There, the entire path is present. Mateusz
Back to comp.os.msdos.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Booting process 0: how to find out its full path? Mateusz Viste <mateusz@xyz.invalid> - 2021-11-16 10:44 +0100
Re: Booting process 0: how to find out its full path? "Auric__" <not.my.real@email.address> - 2021-11-16 16:54 +0000
Re: Booting process 0: how to find out its full path? Mateusz Viste <mateusz@xyz.invalid> - 2021-11-16 18:07 +0100
Re: Booting process 0: how to find out its full path? "Auric__" <not.my.real@email.address> - 2021-11-16 18:49 +0000
Re: Booting process 0: how to find out its full path? Mateusz Viste <mateusz@xyz.invalid> - 2021-11-16 20:46 +0100
Re: Booting process 0: how to find out its full path? JJ <jj4public@gmail.com> - 2021-11-17 08:23 +0700
Re: Booting process 0: how to find out its full path? Mateusz Viste <mateusz@xyz.invalid> - 2021-11-17 09:11 +0100
csiph-web