Note that in addition to specific programs that accept donations, this list includes "Gifts to the U.S. Government" with no strings attached and "Gifts to Reduce the Public Debt".
You can build single-file executables for .NET 4, and I do, but there's no static linking, so you need to restrict yourself to assemblies that ship with the framework and whatever other prerequisites you're willing to install or assume will be installed.
Two notable caveats:
1. Certain newer C# language features require runtime support that doesn't ship with older versions of .NET, which can include quite a few DLLs.
2. In-process COM components can only be instantiated in .NET runtimes runtimes with the same processor architecture, even if the .NET program itself is processor-independent (which by default will use the runtime matching the native architecture), so you may need to ship multiple executables to match multiple COM dependency versions even if your program is otherwise processor-independent or you only intend to ship it for a single processor architecture.
For example, if you build a processor-independent program that relies on the Microsoft Access DAO library, it will by default work correctly on 32-bit Windows if 32-bit Access is installed, and on 64-bit Windows if 64-bit Access is installed, but there's no way to get it to work on 64-bit Windows with 32-bit Access without shipping a second executable (that can be identical with the exception of the 32BITREQUIRED flag in the CLR header[1] that can be set as part of the build process or with the .NET SDK corflags utility).
Rather than ship separate "32-bit (or 64-bit with 32-bit <bar>" and "64-bit" versions of a program <foo> that interops with some in-proc COM component <bar>, I prefer to build a single executable <foo>.exe, then create a copy <foo>32.exe with the flag set as part of the build process, and ship both to be installed side-by-side.
Then, since the native COM DLL isn't loaded until you actually create an interop object referencing it, you can just try to create an Interop.<Bar>.<something> object at program start, catch ComException with HResult == REGDB_E_CLASSNOTREG, then in the exception handler, run <foo>32.exe as a subprocess with identical command-line arguments and exit with <foo>32's exit code, unless you're already running in a 32-bit CLR, in which case you just fail normally.
Funny you mention that. I had to get special permission to use my HP-15C on a "calculators allowed" exam in a first-year "calculus for non majors" course, and had to show the instructor how to reset its memory.
Which I found amusing, because the list of approved calulators included several graphing calculator models with computer algebra systems in ROM sufficient to produce correct answers to every problem on the exam, and they're worried about what I might have stored in the memory of a (then) 15-year old keystroke programmable calculator with a single line, ten digit, seven segment numeric display.
In a world where trainees are sent directly from the gym to the front lines to fight in power armor against power armor-equipped opponents, they probably should.
Not really. An independent Mac company with 8% of Apple's sales would still be the #3 computer manufacturer behind Dell and HP, and Mac gross margins could easily support significantly larger investments in OS development if Apple chose to do so.
What does this bill have to do with age verification?
It legally mandates the existence of a required "age" field in user account records, a user interface to populate it during account setup, a mechanism for service providers to read this field, and that providers act as if it has been populated accurately.
As someone who has been the de facto "system administrator" for my family's computer systems since kindergarten, this has to be one of the stupidest policies I've ever seen gain traction.
Doubtful it's healthcare, as unlike other benefits like stock options, consulting firms will have substantially similar healthcare costs that will be reflected in their fees.
Possibly a legal reason: the product is a headphone that outputs audio, not a DAC that outputs an electrical signal, so unless the drivers have meaningful ultrasonic frequency response, claiming high sample rate support is arguably false advertising regardless of what the internal DAC is capable of.
https://www.pay.gov/public/search/global?formSearchCategory=...
Note that in addition to specific programs that accept donations, this list includes "Gifts to the U.S. Government" with no strings attached and "Gifts to Reduce the Public Debt".
reply