Comments URL: https://news.ycombinator.com/item?id=48648294

Points: 11

# Comments: 13

Some believe Gary Kildall picked CRLF for CP/M since he used DEC TOPS-10 to develop CP/M. see https://www.quora.com/Why-did-CP-M-stick-with-the-CR-LF-stan...

Like Caesar's supposed "Veni Vidi Vici" saying, people seem to prefer and remember items when grouped in three.

I recall a public speaking film shown to my management science class starring John Cleese mentioning this rule of 3.

Similar to Electron, but using an MS Edge browser window control as the webview control instead of Google Chrome.

It's lighter weight than Electron, if you consider that Webview2 ships with Windows and is shared with other Webview2 consumers as opposed to Electron apps which each ship with their own self-contained web browser.

This was exposed through the UI by letting the user adjust the date & time for the RA instance (e.g. move this week's thursday 4pm meeting to 2pm) via drag-drop or editing the RM instance and change the time in the appt dialog.

So I assume with Outlook you could schedule a recurring appt for the common case - weekly appt on wednesday at 1PM. Adjust as your needs require - no meeting needed? Delete this week's instance. Need to move the meeting earlier or later? Go and reschedule this week's instance.

Obviously wouldn't work if you needed two meetings in a week.

see https://hardcoresoftware.learningbyshipping.com/p/021-expand...

and

https://hardcoresoftware.learningbyshipping.com/p/bonus-the-...

Outlook was late so Schedule+ was included in Office 95 for the Win95 release and so Schedule+ got a wider retail consumer release than if it had been just included with the Microsoft Exchange Server 4.0 release.

from https://www.reddit.com/r/software/comments/v73bk7/microsoft_...

  I've been using Schedule+ 95 to keep track of my daily activities since forever. I even modified my Windows install to keep it fully compatible after WinHlp32 was nixed in Windows 10. However, it is increasingly showing its age, and there are certain aspects where I would prefer a more modern solution; I can't integrate Sched+ with my smart phone easily ...

  I'm explicitly NOT looking for any cloud or web apps. I don't have reliable internet nor are all of my daily use machines fast enough to reliably, and responsively, display 90% of the bloated webapps out there. I want something lean, fast, and native for the desktop. Schedule+ uses a max of about 7MB of RAM and I don't want to go over 10-20.

  The CBC, which began televising NHL games in 1952, had operated under that agreement since Rogers Sportsnet acquired the league’s Canadian rights in 2013 for $5.2 billion.

Comments URL: https://news.ycombinator.com/item?id=48581648

Points: 12

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=48574730

Points: 4

# Comments: 2

Another dev who's fixing a bug, realizes if they call a certain function either directly or indirectly, their particular bug gets fixed.

Oh, and as a side effect, the cell gets erased (again).

A few more fixes/new features added like this and the code is inadvertently erasing the same cell multiple times.

It takes a certain type of dev to step through in a debugger and Notice the app is doing way too much work and then to untangle the mess of code without causing regressions.

But there wasn't any similar programmatic debugging aid for detecting uninitialized stack memory.

Going further down the rabbit hole, I discovered the _chkstk function.

The MS C compiler would emit a call to _chkstk on function entry to ensure that stack memory had been paged in. But further reading noted that _chkstk was only emitted if the function allocated a lot of stack memory. And there was source code! MS included the assembly language source code for _chkstk in the CRT source code, installed with compiler.

I needed _chkstk to be emitted for every function not only for functions that allocated >= 4KB of stack variables.

Curses, foiled again.

Then, while perusing the list of compiler command line switches, I see "/Ge".

  /Ge (Enable Stack Probes)

  Activates stack probes for every function call that requires storage for local variables.

I had all the pieces I needed to fill uninitialized stack memory with a non-zero canary value so I could make detection of uninitialized stack variables more reliable.

_stkfil was born

Modifying _chkstk was easy. I needed to write to every byte of stack in a stack page instead of reading only 4 bytes and skipping to the next page of stack.

While I was mucking in the bowels of modifying _chkstk, I added a 4-byte global variable to hold my canary value. Let the app override what value to use.

In debug builds, _stkfil helped find a couple of bugs, but soon all the stray uninited stack vars were gone and the code was forgotten.

Then I read about InitAll in https://www.microsoft.com/en-us/msrc/blog/2020/05/solving-un...

  InitAll - Automatic Initialization

  In addition to the previously mentioned approaches, Microsoft is now using a feature known as InitAll which performs automatic compile-time initialization of stack variables.

  This section documents how Windows is using this technology and the rationale for why.

  Current Windows Settings

  The following types are automatically initialized:

  - Scalars (arrays, pointers, floats)
  - Arrays of pointers
  - Structures (plain-old-data structures)

  The following are not automatically initialized:

  - Volatile variables
  - Arrays of anything other than pointers (i.e. array of int, array of structures, etc.)
  - Classes that are not plain-old-data

  For optimized retail builds, the fill pattern is zero. For floats the fill pattern is 0.0.

  For CHK builds or developer builds (i.e. unoptimized retail builds), the fill pattern is 0xE2. For floats the fill pattern is 1.0.

see https://www.cbc.ca/news/business/ontario-ticket-resale-cap-e...

I'm explaining why the infinite loop actually occurs for those who haven't encountered the problem.

The problem would happen for an array whose beginning element starts at offset 0 for a particular segment and an iteration stop condition that uses ">= 0th element" that scans down the array. I used a 64K allocated array to ensure that the array base would match offset 0.

Problem would also occur if the end of the array aligns with the segment limit and the iteration end condition was "<= end element" and the scan moves up the array.

For either situation, the array could be < 64KB. One byte would be sufficient.

The above example would cause an infinite loop on Win16's seg:off far memory model, but compiling on Win32 would not cause an infinite loop.

Problem is that far pointers only affect the offset, not the segment. So decrementing a 0 value offset would just wrap around to 0xFFFF and the segment would stay the same, so you're going from mem[0] to mem[65535] not mem[-1].