The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
We had a DOS application, DBase II based, so large that the cover had to be taken off machine for it to fit in...
You start the program. It crashes. After trying "everything", you give up and send the PC to the IT guys for hardware debugging. They take off the cover, get the probes in place, and everything works fine. They return the PC to the user: It fails. Back in the workshop, it works fine. After several round trips it was discovered that it works when the cover is off, fails when the cover is on. It took a few more rounds before the true explanation was found.
In those days, many tower cabinet covers were shaped like an (upside down) U, running in tracks that forced you to pull it backwards all the way to get it off. This was a deliberate design to force you to unplug the power cord before opening the machine. You unplugged not just the power cord, but all sorts of cables - screen, printer, keyboard and whathaveyou. That's the clue:
Windows 2.x had arrived, but most programs were still keyboard based. So was this DBaseII application. The IT guys, when testing the machine, opened it, plugged in power, screen and keyboard, but not the mouse - it wasn't needed for testing. The PC booted, the mouse driver initialized, found no mouse to talk to, so it unloaded itself, releasing a couple hundred bytes of RAM.
Back at the office, everything including the mouse was plugged back in. The mouse driver did not release its space. When loading the DBase-application, there was no check, no error report that RAM size is too small, the program won't fit! Maybe an error return was genereated deep inside, but it never reached the user before the system crash was a fact.
When the real problem - insufficient RAM - was identified, memory could be tweaked in other ways, to allow the mouse to remain plugged while this application was running. But for a couple of weeks, it was a great mystery to us how it could be that you had to remove the cover to make space for the program.
When I built my first computer in the 70's (z80 based), I didn't have DOS. All I had was a 2K monitor called Zapple. I didn't have an assembler so I learned to program by the numbers. No external storage till I wire wrapped a card to write data to a cassette drive (I actually used a reel-to-reel). The system eventually grew into a CPM system with dual 8 inch floppy drives. Those were fun days.
One of my early jobs was with a company building minicomputers. Every manufacturer had their own OS in those days. I happened to discover a reproducible situation sending the OS into an infinite loop. I went to one of the OS guys, describing it, and he dug out a hardcopy printout of the source code. We did all application programming in high level languages then, but the OS was written in a language at somewhat lower than C - you could maipulate registers directly, and use inline assembler when needed.
After about fifteen minutes of grunting, flipping back and forth bewteen the pages of the OS listing, he nodded a "yes!", grabbed his pen and wrote two numbers into the source code - two 16 bit values in octal format. I asked him what that was. "Oh, that's the patch for it".
He had jotted down not the source code change. Not the assembler instructions that would be generated by the language compiler, but the octal codes for those assembler instructions. Why? Because he would try out the patch by poking directly into the running OS code of his test machine, and then it is very convenient to have the value ready in advance.
Yeah, I suppose he was right. But he didn't need to look up the instruction code anywhere before jotting it down in the listing, so I guess he could have managed with the assembler instruction as well. But why bother with instruction names, when you know the instruction code.
Jira has become a victim of its own success. It started out as a bug management tool and it has bolted "feature" after "feature" on top. Each one has become more and more clunky because the underlying model was never meant to behave in the ways that people want to use it now.
So I have a post build event in my .csproj with the idea that I want to run dotnet publishafter I built the code in Visual Studio. But, because dotnet publish picks up the post build event as well, guess what. Inf***ingite loop.