| 00:09.30 | *** join/#maemo xes (~xes@unaffiliated/xes) |
| 00:16.40 | *** join/#maemo cyteen (~cyteen@cyteen42.plus.com) |
| 00:23.13 | *** join/#maemo xes_ (~xes@unaffiliated/xes) |
| 00:35.45 | *** join/#maemo DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 00:36.12 | valerius | DocScrutinizer05 I think that you're not right regarding windows. Windows is a system that inherits DOS. Since DOS, it's possible to add env. variables with "set" commands. So, these variables are set in the current shell, and get inherited by child processes. Also, the "root" environment variables can be set in autoexec.bat. This is a gobal env. variables for a "root" shell. DOS had child processes to, and they inherit the environment of the parent |
| 00:36.12 | valerius | . The same is in windows. Parent cannot get its child's environment. But what windows adds is a possibility to redefine a "root" environment (in settings of "My computer" icon). So that, the global environment change takes effect in all process hierarchy, immediately, i.e, without a reboot. So, the intent is to do that without a reboot. Otherwise, it is done the same way as in UNIX. The only difference is the absence of "export" command, but that's |
| 00:36.12 | valerius | <PROTECTED> |
| 00:37.46 | DocScrutinizer05 | valerius: you might be right, i'm no windows expert |
| 00:38.07 | valerius | autoexec.bat can be thought of as "init scripts" in DOS |
| 00:38.18 | valerius | DocScrutinizer05 me too :) |
| 00:38.44 | DocScrutinizer05 | I'm just pretty sure windows allows global changing of env vars and I know the better half od details how unix works |
| 00:41.00 | DocScrutinizer05 | I never meant to claim parent could get childs env, what I meant was child can't change parent's env |
| 00:41.20 | DocScrutinizer05 | in unix, and it can in windows |
| 00:43.35 | DocScrutinizer05 | I mean I seem to recall in windos you can start an editor of sorts (-> it's a child) to edit global env vars (so owned by (grand)parent) |
| 00:43.44 | valerius | I doubt that. You can only change the root environment with "My Computer" icon. Simple windows processes can't do that. I'm not sure, of course, if a windows program can call an API changing the "root" environment. Maybe, it could, but I cannot tell for sure |
| 00:44.32 | valerius | I'm not a windows expert too :) |
| 00:44.48 | DocScrutinizer05 | well, HOW do you change that? you need a process for doing that and that process is... a child of the process defining the vars, no? |
| 00:45.50 | DocScrutinizer05 | or maybe not even that |
| 00:46.03 | valerius | hm, not sure. Maybe that requires special privileges, and only "explorer" could do that |
| 00:46.23 | DocScrutinizer05 | that's irrelevant for the general architecture |
| 00:46.55 | valerius | needs to ask about that on #reactos ;) |
| 00:47.07 | DocScrutinizer05 | meh, anyway I'm really not the one to disczuss windows idiosyncrasies with |
| 00:47.27 | valerius | :) |
| 00:48.09 | DocScrutinizer05 | I just tried to give some reference where unix might surprise users that are familiar with the way windows works, the topic was unix env vars though |
| 00:48.52 | DocScrutinizer05 | and you define unix env vars in parent and children inherit a copy basically |
| 00:49.16 | DocScrutinizer05 | children never gave write access to parrent address space |
| 00:49.31 | DocScrutinizer05 | have* - for (env) vars |
| 00:50.06 | valerius | Yes, the question was about the UNIX environment, I agree. But DOS and DOS-based OS'es took this idea from UNIX, so they work the same |
| 00:50.11 | DocScrutinizer05 | parent and child can share a memory segment, env vars are not in such shared segment though |
| 00:51.20 | valerius | yes, that's logical |
| 00:52.42 | DocScrutinizer05 | i think "man fork" and/or "man execve" might have details how parent copies env vars into child's address space |
| 00:54.57 | DocScrutinizer05 | and for a windows user it might be puzzling to not find a whatchacalledit... "root environment with "My Computer" icon" to change env vars |
| 00:55.08 | DocScrutinizer05 | in unix |
| 00:59.49 | valerius | yes, agree |
| 01:04.29 | DocScrutinizer05 | >>The fork() function shall create a new process. The new process (child process) shall be an exact copy of the calling process (parent process) except as detailed below: ... [no env vars mentioned in there, so they are a copy] ...<< |
| 01:04.48 | DocScrutinizer05 | from man 3p fork |
| 01:08.13 | DocScrutinizer05 | well, that's also a pathetic rationale by me, env vars could get stored in any memory range that's world r/w and processes copy pointers to that memory (which is prolly what windows does) |
| 01:08.39 | DocScrutinizer05 | anyway in unix they are not stored in such public place |
| 01:19.05 | *** join/#maemo infobot (ibot@rikers.org) |
| 01:19.05 | *** topic/#maemo is Welcome to #maemo http://maemo.org/intro/ | N9/harmattan related questions please in #harmattan ! | "firmware" see ~lf (or ~tabletsdev ~combined ~emmc ~flasher) sdk: ~sb | http://wiki.maemo.org/Community_Council | Source: http://wiki.maemo.org/Sources | Chanlog: http://mg.pov.lt/maemo-irclog | #maemo-ssu is where the (few) devels and maintainers of the maemo-future meet |
| 01:19.55 | DocScrutinizer05 | how are arbitrary processes downstream the explorer hierarchy (read: children of explorer)? |
| 01:20.22 | DocScrutinizer05 | but honestly, this is sort of OT for maemo |
| 01:25.18 | Maxdamantus | Presumably when getting explorer to start a new program, the new process will have a copy of explorers environment, with changes specified by configuration like global variables and variables set in the shortcut, if relevant. |
| 01:25.23 | valerius | DocScrutinizer05 The global environment is somewhere in a "win32" subsystem. Explorer is just a windows task that could configure the whole subsystem settings, including the environment. Maybe, it's changing only its own environment, and that's sufficient, because it starts all other user processes. So, it can be thought as a login shell. So, it could change it's own environment. I'm not sure, how it's gets propagated to all children. |
| 01:25.36 | Maxdamantus | explorer's* |
| 01:26.40 | valerius | Maxdamantus Yes, maybe env changes are propagated only to newly-stared processes, but not the old ones |
| 01:29.01 | valerius | *started |
| 01:29.34 | *** join/#maemo heroux (sandroco@gateway/shell/insomnia247/x-btndaonovwpyhdnr) |
| 01:29.44 | Maxdamantus | I think the general expectation would be that most programs are started through explorer anyway. |
| 01:30.30 | Maxdamantus | unix-like systems don't really have that expectation; if someone starts a program from bash, bash directly forks/execs that program. |
| 01:30.45 | Maxdamantus | instead of sending some message to the init system to start it. |
| 01:33.00 | *** join/#maemo HRH_H_Crab (~crab@kowloontong.dim-sum.org) |
| 01:33.00 | *** join/#maemo DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 01:33.00 | Maxdamantus | and if you start it from a file manager, the file manager probably forks/execs .. if you start it from some menubar program, that probably forks/execs, etc |
| 01:33.00 | Maxdamantus | (not that I use file managers or menubars, so might be mistaken as to how they're likely to work) |
| 01:37.05 | *** join/#maemo yosafbridge (~yosafbrid@68.ip-149-56-14.net) |
| 01:37.21 | valerius | Maxdamantus hm, I tried to start Far manager in windows, then change the global environment, and then run a compiler from inside Far. It seems, the environment change took an effect in Far's children too, though they are not started directly by explorer. But I'm not sure. |
| 01:37.48 | valerius | Yes, we have gone into offtopic, I agree ;) |
| 01:38.29 | Maxdamantus | Yeah, so I'm wondering if such programs will communicate with explorer to get it to start the program instead of directly calling `SpawnProcess` itself. |
| 01:44.00 | Maxdamantus | Actually, that's probably not right. |
| 01:44.04 | valerius | Anyway, new programs are started by the win32 sybsystem by parent's request. So, explorer could ask the subsystem to change its global environment, so that all programs started get new environment changes from the central place. No matter, which process starts a child. It still needs to call an API from the win32 subsys. So, the sybsys copies env. variables from the parent's environment to child's one, and adds some new global vars from the global |
| 01:44.04 | valerius | <PROTECTED> |
| 01:44.21 | Maxdamantus | Since I vaguely remember being able to do things like start explorer from the task manager. |
| 01:44.57 | valerius | they are communicating, but not with explorer. They communicate with win32 subsystem, I think |
| 01:45.50 | valerius | yes, task manager can restart explorer -- it seems to be higher in the process hierarchy |
| 03:01.23 | *** join/#maemo tm (~sinnlos@unaffiliated/tm) |
| 04:26.38 | *** join/#maemo FalconSpy (falconspy@unaffiliated/falconspy) |
| 04:34.21 | *** join/#maemo povbot (~supybot@office.pov.lt) |
| 05:13.50 | *** join/#maemo DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 05:41.33 | *** join/#maemo vahe (~vahe@unaffiliated/vahe) |
| 05:42.09 | *** part/#maemo vahe (~vahe@unaffiliated/vahe) |
| 06:41.20 | *** join/#maemo ceene (~ceene@collins.gmr.ssr.upm.es) |
| 06:59.54 | *** join/#maemo eMHa (~mh@p54B0F863.dip0.t-ipconnect.de) |
| 07:05.08 | *** join/#maemo cyteen (~cyteen@cyteen42.plus.com) |
| 07:18.16 | *** join/#maemo vahe (~vahe@unaffiliated/vahe) |
| 07:18.41 | *** part/#maemo vahe (~vahe@unaffiliated/vahe) |
| 07:26.19 | *** join/#maemo jskarvad (~jskarvad@ip4-83-240-32-61.cust.nbox.cz) |
| 07:26.19 | *** join/#maemo jskarvad (~jskarvad@redhat/jskarvad) |
| 07:30.00 | *** join/#maemo vahe1 (~vahe@unaffiliated/vahe) |
| 07:33.10 | *** join/#maemo vahe (~vahe@unaffiliated/vahe) |
| 07:36.01 | *** part/#maemo vahe (~vahe@unaffiliated/vahe) |
| 07:37.56 | *** join/#maemo oniongarlic (~milang@tori.tal.org) |
| 07:43.04 | *** join/#maemo vahe (~vahe@unaffiliated/vahe) |
| 08:23.53 | *** join/#maemo ecc3g (~eccerr0r@2602:46:3913:b400:5054:ff:fe37:7e04) |
| 08:25.55 | *** join/#maemo geaaru (~geaaru@host170-152-static.43-88-b.business.telecomitalia.it) |
| 08:30.48 | *** join/#maemo vahe (~vahe@unaffiliated/vahe) |
| 08:30.53 | *** part/#maemo vahe (~vahe@unaffiliated/vahe) |
| 09:05.48 | *** join/#maemo ceene (~ceene@collins.gmr.ssr.upm.es) |
| 09:20.08 | *** join/#maemo TheKit (~nekit@85-95-179-113.saransk.ru) |
| 09:24.52 | *** join/#maemo freemangordon_ (~ivo@195.242.126.12) |
| 09:30.09 | *** join/#maemo cyteen (~cyteen@cyteen42.plus.com) |
| 09:38.42 | *** join/#maemo florian (~florian_k@Maemo/community/contributor/florian) |
| 09:46.28 | *** join/#maemo spiiroin (~spiiroin@2001:998:2a:dead:315b:fc8:309f:7a4a) |
| 09:49.24 | *** join/#maemo xorly (~xorly@ip-86-49-24-93.net.upcbroadband.cz) |
| 10:16.49 | *** join/#maemo eMHa (~mh@81.26.162.98) |
| 10:38.42 | *** join/#maemo eMHa (~mh@81.26.162.98) |
| 10:39.15 | *** join/#maemo xes_ (~xes@unaffiliated/xes) |
| 11:07.19 | *** join/#maemo pkill9 (~pkill9@unaffiliated/pkill9) |
| 11:09.44 | *** join/#maemo SmilyOrg (~SmilzOrg@ip5f5bf5df.dynamic.kabel-deutschland.de) |
| 11:31.59 | *** join/#maemo aloril (~aloril@dsl-tkubng11-54f948-150.dhcp.inet.fi) |
| 11:39.58 | *** join/#maemo dafox (~dafox@2a02:a448:c25a:1:7061:3b2a:37df:ded3) |
| 12:19.00 | *** join/#maemo qwazix (~qwazix@Maemo/community/ex-council/qwazix) |
| 12:23.14 | *** join/#maemo cyteen (~cyteen@cyteen42.plus.com) |
| 12:37.00 | *** join/#maemo aloril (~aloril@dsl-tkubng11-54f948-150.dhcp.inet.fi) |
| 12:54.34 | *** join/#maemo Smily (~SmilzOrg@ip5f5bf5df.dynamic.kabel-deutschland.de) |
| 13:20.38 | *** join/#maemo jskarvad (~jskarvad@redhat/jskarvad) |
| 13:43.52 | *** join/#maemo aloril (~aloril@dsl-tkubng11-54f948-150.dhcp.inet.fi) |
| 13:48.04 | *** join/#maemo zGrr (~Grr@185.13.106.201) |
| 14:06.01 | *** join/#maemo xorly (~xorly@193.85.203.185) |
| 14:16.18 | *** join/#maemo varu- (~whee@67.213.82.179) |
| 14:33.30 | *** join/#maemo vakko (~vakko@vlan-152-aitos-139.comnet.bg) |
| 15:17.16 | *** join/#maemo spiiroin (~spiiroin@82-203-191-179.bb.dnainternet.fi) |
| 15:43.11 | *** join/#maemo jskarvad (~jskarvad@ip4-95-82-147-159.cust.nbox.cz) |
| 15:43.11 | *** join/#maemo jskarvad (~jskarvad@redhat/jskarvad) |
| 16:00.29 | *** join/#maemo CatButts (~c@188.173.53.45) |
| 16:00.36 | CatButts | butts |
| 16:05.32 | enyc | blinks |
| 16:11.15 | bencoh | mreows |
| 16:26.08 | *** join/#maemo Kabouik_ (~kabouik@236.34.200.37.customer.cdi.no) |
| 17:02.17 | *** join/#maemo LauRoman (~LauRoman@5-14-29-47.residential.rdsnet.ro) |
| 17:15.05 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 17:27.46 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 17:34.12 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 17:35.44 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 17:37.45 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 17:42.03 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 17:45.20 | *** join/#maemo Juesto (~LimeC@rev190-105-167-003.pccp.net.ar) |
| 17:46.46 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 17:51.42 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 18:15.11 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 18:27.18 | *** join/#maemo pkill9 (~pkill9@unaffiliated/pkill9) |
| 18:54.42 | *** join/#maemo LauRoman (~LauRoman@5-14-29-47.residential.rdsnet.ro) |
| 19:12.25 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 19:33.47 | *** join/#maemo xorly (~xorly@ip-86-49-24-93.net.upcbroadband.cz) |
| 19:42.32 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 20:06.01 | *** join/#maemo florian (~florian_k@Maemo/community/contributor/florian) |
| 20:20.13 | *** join/#maemo NotKit (~nekit@95-83-18-7.saransk.ru) |
| 21:08.57 | *** join/#maemo eMHa (~mh@p54B0F863.dip0.t-ipconnect.de) |
| 23:08.11 | *** join/#maemo Alexxxlrus (~Alexxxlru@5.3.243.2) |
| 23:38.09 | *** join/#maemo Alexxxlrus (~Alexxxlru@5.3.243.2) |