Some clone makers quickly found out ways take advantage of that space adding more RAM there. Then bit later it came area where you could even map over 1MB placed memory blocks there with a config.sys loaded driver.

So is that CreateProcess much different from nix execve() which passes just a pointer to string of executable first followed by pointers to arguments *argv[], and process environment same way *envp[]?

Thus it is the shell which responsibility is to expand all wildcards before passing to that executable arguments nix systems, which do not expand any wildcards itself before passing to executed program.

I'm no Windows programmer so, genuinely what's the difference from point of executed program and just that Windows any shells do not expand wildcards etc. ?

My previous post when I did mention that alternative c0.obj (not lib, sorry) that I for example had about 36 years ago from somewhere was a nifty modified trick which took that plain dumb MS-DOS COMMAND.COM passed string and instead just making it a char *argv[] array first expanded wildcards before your main() got control. It did work very well and saved quite bit of effort when I ported some tools to MS-DOS and I think there was another version of it for OS/2 (1.something) that I used also.

I did not have to add ported software from unix any command line expanding code myself because that alternative startup c0.obj did it for me. Shame I do not remember where I got it and who did it, but it was really good. Now thinking of it perhaps it was from Compu$erve some forum or WSMR-SIMTEL20 archive.

I remember that also Fabrice Bellards lzexe and something spawnsq() (not sure about exact name any more) library also was in use. The latter swapped (saved out file) out running most of MS-DOS program before executing like execve() and freed a lot more memory to run that other program then loading it back when called program was done. I think it used something like 8k memory while resident when other called was running. Which was often enough and no need do any horrible .BAT rewrite tricks to able to accomplish same functionality.

Yes, mostly proprietary third party systems which abtracted complexities away from programmers placing their trust to that often not even sure your language vendor was not belly up or with good luck purchased by someone else who then told you we do not support it any more next year. And left you to deal with that. Not fun, not even close I may add. I know who weren't so lucky and had to gather pieces at least mostly rewriting things again new toolkit.

Software development invests in that written code and you learn to appreciate that when you got a lot of it understanding how large and costly task it would be to rewrite another language. Especially then it was that. Now LLM's, much better IDE's etc help a lot with that. Today standards thinking you do not make fair comparison what it was back then.

>...have you ever tried to write portable C code in K&R C without it being full of #ifdefs?

Yes I have done it, not just tried. It wasn't too bad after all when you knew how to do it. Most of systems dependent were hidden away by ourselves to .h files and some to libraries we did. That time it was common thing to teach even, and if not learn from others code how to do it.

That way we knew we had better chance easier to port it something even remotely close existing kind of platforms and OS's. Investment in written software as too great to ignore.

But, did you lately or when did last time write software without relying those abstractions being hidden away either device vendor language libraries or third parties modules?

While you think of it, let me tell you that this situation where we are now is so much much less diversity with our target systems and plenty of programming languages with multitude of good libraries and ready made modules do not compare at all to what situation was end of 80's. Comparing software development effort today's languages and tools by then doesn't make sense at all. Everything was so much slower and time consuming.

That area where C-language is still relevant is now much narrower, but there still are niches where I understand it fairly well. I also understand that you don't get it but that is not a my problem, it's more of a you problem if that irritates you from my point of viewing this matter.

But whatever written here for before above, I see no value continuing this argument with you any more. If you haven't this far understood what I tried conveying there is no hope with me you will eventually get what I try to explain.

So by that I'm wishing you a nice day, cheers.

It tells me more about some people not being curious enough to read documents and explore environment they work than others apparently.

Assembler generating was long time a standard feature of compilers simply because writing the assembler code was easier than directly runnable or linkable object code. And for language designer and compiler programmer it was easier to read verifying correct code generating that way. Why bother writing assembly compiler, linker etc. when you usually already had them in the system that time.

Then later it changed bit as vendors did not any more ship any or just some crippled compliers to compile just a new kernel with the base system to curb their language competition. Which made third party compilers had to either provide with complete set their own creating executables or ask buyer also licensing system vendor compiler toolkit which they would not otherwise need. That then caused prospect third party compiler customer add that licensing fee top of offering and compared which option they would buy if any. That was time when developement toolkits started changing. Under MS-DOS there never was compiler shipped with it that was a situation all the time, but with the minis and larger systems more what described here above.

ps. I think you get much too wound up about C-language. For a long time there was no real alternative use to cross environments compatible way developing thing without major rewrite each platform. That what mattered more than anything else then and in some sense also to some these days also. And no language needs to be put on pedestal like you wrote message you already changed or deleted so that I did not get to answer.

It was then COMMAND.COM ie. Dos command line did not do that. And there were alternatives like something called 4DOS which I did never use, but those could have done it. Or did they?

I have't used Windows for quite long time. And I do not know if CMD.EXE or PowerShell whatever its name are any better. Maybe someone knowing would like to comment this.

There have been some writings and posts here about Microsoft. Here is one from last spring, from a guy that was long time Windows core developer and moved to Azure group. It's well worth reading, what he writes about challenges they have had and most likely still have if not even worse now.

https://isolveproblems.substack.com/p/how-microsoft-vaporize...

and the related HN thread

https://news.ycombinator.com/item?id=47616242

And from what I've understood old chaps like Dave Cutler are involved much less than they were for a very long time.

s/ARAIC/AFAIC/g s/70kb/720kB/g

Linked post is quite good and had forgotten completely XEDOS mentioned Byte article.

The problem with changing / to - was, that under MS-DOS command line parsing was left completely to a a loaded program, which then would had to know how to find out this change and act accordingly. And if not only MS-DOS std. utilities behaved properly and others not so much. Thus causing confusion which perhaps then lead to dropping that feature 3.0 onwards.

I think it was also before 2.0 or at least what delivered with Apricot PC (UK made PC) 1.25 which I tinkered with few days as we had it on display from Finnish importer ARAIC Rautakirja Oy (Finnish railways VR magazines and other related travel reading importer, also keeper of the R-kiosks). A very nicely built non IBM PC compatible PC with good graphics and then uncommon 3.5" 70kb disk drives before Apple Macintosh made the more popular.

https://www.homecomputermuseum.nl/en/collectie/act-computers...

e: Now did it change also path separator from \ to / ? It may have done it also. I bit later work more with Xenix and can't remember for sure. Starting from 286 versions SvR2.x, 386 SvR3.x up till SCO UNIX SVR4 early 90's and less with MS-DOS besides maintaining couple of TSR's I had written and just checked every MS-DOS release that those still did work.

Then few weeks after finishing book I ran into his LinkedIn post (bit OT sure) if what book told was his recollection still accurate in part where book refers his work at DEC Systems Research Center (SRC) at the time. Following is what he replied to me:

" markoff and hafner did extensive research and the book is accurate in all ways i could know. note that while mitnick has paid his debt to society (jail time), i've never received from him an apologia. my only other written mention of those breakins was here:

https://www.linkedin.com/pulse/burdens-blame-paul-vixie/ "

But for example ^T (letter transpose) do not work on macOS Firefox, which I'm quite accustomed to use also. But ^T works fine same macOS Safari and Chromium.

Firefox apparently has its own input method which do not implement all what macOS supports.

*) https://cs.wellesley.edu/~cs249/Resources/ed_is_the_standard...

Yes, 34 years and no plans to switch.

Emacs cursor movement keystrokes are quite widely supported elsewhere too which use GNU readline or implement at least subset themselves.

Those work well also besides shells with Chromium/Chrome/Safari etc. many browsers input fields (address bar and text area). Cisco IOS, Juniper Junos, Netscreen load balancers too etc. IMHO makes jumping around CLI much much convenient and faster than moving hand to reach cursor keys.

My only gripe is that Firefox and its derivatives it doesn't work any more. Long time ago it did work. And I have no idea why feature was dropped some rewrite.

e: s/deadline/readline/g

IBM Memo, Novel Netware etc. groupware and such X.400 and routing those required also odd email conventions. VAX VMS addresses did have % left side routing in too.

But if used as a senders source address there are even less limits.

For example you can use a null address <> when sending. That has been used bit less these days than earlier. It's been used ages SMTP delivery status notifications, mail loop prevention and so where intentionally not much sense to expect anyone to reply. And all well known MTA's forward it and email clients handle it very well by disabling reply to that message.

There is however a catch that anyone who thinks he would now start using it when he doesn't want any reply. Ever since IT Service Management (ITSM) and Service Desk software appeared, they have had issues with email coming from <> sender, because they like to always add received messages email addresses to database, where then someone handling would reply. I've been using only few, Service Now (SN) more lately and before Issue Tracker (IT), both didn't at least about year and half ago know how to handle null sender addresses. Both seemed to just discard or sort some trash bin those emails. With our SN sysadmin didn't find where those went in that system.

But otherwise <> as a sender works great. And sure it would be great if those ITSM making folks would get this fixed, because when your postmaster, postmaster, etc. and such role-aliases are the quite often handled by ITSM software, there is good chance you don't get some important notifications from systems that rely on that null address sender.

ps. Search Google: smtp and sender address as "<>" for more info incase needed.