Some Thoughts on Spelling Fixes
- Keep number of changes small.
- Use separate commits per directory
- Use descriptive commit messages
- Set your email correctly
- Don't correct code
Keep number of changes small
Use separate commits per directory
Use descriptive commit messages
Set your email correctly
Don't correct code
Venix Emulator Update
Tracking down a silly bug
ls: Sig 44
That's weird. So I added tracing. I tried the cc command, which in this version is a simple program that orchestrates all the different parts of the compiler using fork, exec, dup and the strategic close/open pair to setup stdin etc. All the tracing looked good as well, we'd see something like:
123: fork() 124
124: ... lots of stuff
124: exit 0
123: wait pid 124 status 0
and then 123 would proceed to delete all the temp files and exit. It was like it was getting an error, despite its children exiting without an error. Every time it was like this, but only when I ran the optimizer. When I'd re-run the ls test, I'd get different Sig values as well.
Available 8086 compilers in 1985
The wait(2) system call...
which shows wait taking a pointer. So I assumed this was what the kernel received in the first arg that's passed into the kernel (DX). I assumed that DS:DX pointed to an integer where I'd return the status. Most of the time, DX was something that looked like a pointer on the stack, so I just did a copyout. The problem is that's not right.
So, I took another look at the manual. At the end of the man page I saw:
AX = pid of process
DX = status
and then it hit me. DX isn't a pointer to anything. After int 0xf1 AX is the pid of the process (the normal return value) and DX is the status. Disassembling wait.o confirmed this:if statusp is not 0, dx is copied back to *statusp. Doh! The classic pointer vs value mistake. Fixing my implementation to take out the copyout and replace it with setting DX in the processor context made pcc work. And cc worked. And the silly test programs I wrote in the middle to debug things worked. Woo Hoo!
Once I fixed this, all weird combinations of compilations suddenly worked for me. I could optimize, strip, etc and there were no oddities.
Customizing Emacs for Git Commit Messages
(add-hook 'find-file-hook 'imp-git-hook)
will do the job nicely. Next up, we need to define this function to do something useful when run (indeed, failure to define it will result in an error when visiting all files).
(defun imp-git-hook ()
(when (string= (file-name-base buffer-file-name) "COMMIT_EDITMSG")
buffer-file-name is a local variable that has the full path name to the buffer, if any. file-name-base is like basename(1) in that it returns the name of the file without the extension, rather than its whole path.
But what is 'freebsd-git-setup'? It's a little function I wrote to set the fill column to 72 (I usually have it at 80, but that produces commit messages that are just a bit wide when git adds leading spaces) and adds a sponsorship tag to my commits:
(defun freebsd-git-setup ()
(setq fill-column 72)
(if (re-search-forward "^Sponsored by:" nil t)
if (re-search-forward "^\n#" nil t)
(replace-match "\nSponsored by:\t\tNetflix\n\n#")))))
But it only adds the sponsorship tag if one isn't there yet.
This is a proof-of-concept function. No doubt it will have to evolve over time. The project adds 'Differential Revision' tags as the last tag in a commit message because differential requires (required?) that. And it wouldn't be good to add this for non-FreeBSD commits, so I'll have to find a way to filter for that... But I thought this would be useful, if nothing else than to my future self as a roadmap for how to do things like this.
EPSON QX-10 20MB Hard Disk
PT.COM for EPSON QX-10 PeachText 5000 date changed - 02/03/84
and similar references to the QX-10 or EPSON CP/M.
So, this was from a Epson QX-10 CP/M system. Looks to be a soft-water service company from South Bend Indiana. All their books and correspondence from the mid 1980s was on it, along with some interesting disk support software. There's even some bits of Z80 assembler, but they are too disjointed to know what they were for.
I've not been able to get cpmtools to read the disk in a structured way, however, so it's hard to share just the interesting bits. Still working on it.
If you have one of these machines, or are interested in preserving software from it, please let me and we may be able to work something out.
Recovering From Firmware Upgrade
How to Recover
C:\WINDOWS\system32> mountvol w: /sC:\WINDOWS\system32>w:W:\> cd EFI\Microsoft\BootW:\EFI\Microsoft\Boot> ren bootmgfw.efi bootmgfw-back.efiW:\EFI\Microsoft\Boot> copy W:\EFI\FreeBSD\loader.efi bootmgfw.efiW:\EFI\Micorsoft\Boot>
% sudo efibootmgr -vBoot to FW : falseBootCurrent: 0001Timeout : 0 secondsBootOrder : 0001, 2001, 2002, 2003+Boot0001* Windows Boot Manager HD(1,GPT,f859c46d-19ee-4e40-8975-3ad1ab00ac09,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)nvd0p1:/EFI/Microsoft/Boot/bootmgfw.efi /boot/efi//EFI/Microsoft/Boot/bootmgfw.efiBoot2001* EFI USB DeviceBoot2002* EFI DVD/CDROMBoot2003* EFI NetworkUnreferenced Variables:%
% sudo efibootmgr --create --loader /boot/efi/EFI/freebsd/loader.efi --kernel /boot/kernel/kernel --activate --verbose --label FreeBSDBoot to FW : falseBootCurrent: 0001Timeout : 0 secondsBootOrder : 0000, 0001, 2001, 2002, 2003Boot0000* FreeBSD HD(1,GPT,f859c46d-19ee-4e40-8975-3ad1ab00ac09,0x800,0x82000)/File(\EFI\freebsd\loader.efi)nvd0p1:/EFI/freebsd/loader.efi /boot/efi//EFI/freebsd/loader.efiHD(6,GPT,68f0614d-c322-11e9-857a-b1710dd81c0d,0x7bf1000,0x1577e000)/File(boot\kernel\kernel)nvd0p6:boot/kernel/kernel /boot/kernel/kernel+Boot0001* Windows Boot Manager HD(1,GPT,f859c46d-19ee-4e40-8975-3ad1ab00ac09,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)nvd0p1:/EFI/Microsoft/Boot/bootmgfw.efi /boot/efi//EFI/Microsoft/Boot/bootmgfw.efiBoot2001* EFI USB DeviceBoot2002* EFI DVD/CDROMBoot2003* EFI NetworkUnreferenced Variables:%
% cd /boot/efi/EFI/Microsoft/Boot% sudo mv bootmgfw-back.efi bootmgfw.efi%