I think the original version is better because I read it once and was reasonably confident I knew what it did, and also what was intended. The shorter, cleverer version I looked at and said "Eh?". In my first job I discovered that programs might have to survive being "fixed" by a half-drunk trainee who had been dragged from the pub when something went wrong on Friday night at the start of a holiday weekend and all the sober and competent programmers were gone. I know, I was that trainee. OK, so this isn't an IBM 360 COBOL accounting program, but still, clarity of intention is desirable. KISS, in fact.

It is easy, at least with my Dell Optiplex. Power on, press F2 to enter Setup Go to Power Management Select Auto Startup Select EveryDay, or Monday to Friday (default is Off) Set time you want the system to boot up. Save and exit Bios. OK, you asked how to write a program to do it, so this is cheating. But easier.

I came here because I was confused. Now I'm confused on a higher plane.

Ah yes, now I remember, THAT was why we all started using high level languages.

LOW-VALUES is not a literal or a variable, but a "figurative constant". Commonly used to initialise variables, or areas of storage, or for comparisons like IF MY-VARIABLE > SPACES THEN ... LOW-VALUES means binary zeros, the lowest thing possible in the collating sequence. HIGH-VALUES means binary ones, the highest value in the collating sequence. SPACES was the only other figurative constant that I remember. The practice of initialising one chunk of memory with a figurative constant, then using a loop to copy that chunk, was a performance optimisation, minimising the size of the object code and the run time taken. If I remember right, moving a figurative constant like "spaces" or "low-values" to up to 256 bytes took only one machine instruction, but if the target area was longer than 256 then the compiler generated a loop to set one byte at a time. So initialising 256 bytes, then looping to copy the 256 byte chunk, was faster for only a couple of bytes extra memory cost. This program, or at least this part of it, has been written with care by a skilled programmer putting in extra effort to produce a smaller faster runtime, instead of doing it the easiest way. So don't mock. Once upon a time, when dinosaurs roamed the earth, in my first year of programming I was tasked to make a suite of invoicing and sales ledger programs smaller, so that they would fit in whatever was going to be left over from the massive 64K of memory in our mighty 360/30 mainframe, after the new version of the IBM DOS/360 operating system was installed. We only had about 20 spare free with the previous version of DOS. No such thing as multi-programming or virtual memory, and the price of the next hardware upgrade had about five zeros on the end. I spent weeks rewriting little routines different ways and looking at the memory map of the generated code, changing all the literals like " " and " " or "XX" and "XXX" to multiple redefinitions of the same constants, thus saving the vital couple of hundred bytes.