|
I have a 3TB HDD that's basically just adding weight to my machine, but I don't want to dig it out.
Windows is like: "I see you clicked build on a project that runs entirely off your NVMe system drive, let me just make you take a shower/make a sandwich while I spin up your HDD for no reason."
"Oh I see you want to extract a file from a zip in your C: download directory? Let me spin up D and make you wait, while you hear it just to make you mad."
I thinks it's ext4, not even NTFS, but i'm not sure because the only time it gets used is when windows randomly decides to pause everything while it wakes it up.
I keep it in there mostly on the off chance VMs (see my prior posts about VM woes) aren't going to do the job and I need to dual boot, but Windows is hurling it like a brick straight through my workflow.
So now I have to dig it out, because in their infinite wisdom Windows designers thought that spinning up the drive during unrelated operations would be some kind of win.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Just wait till they 'cloud'-ify everything in the next iteration of Windows - it will be SO MUCH BETTER!!! 
Their hubris is almost unbearable. How many years has it been, and you still can't place the start menu on the right or left sides of the screen, like you could in Win10?
It's going to get worse...
|
|
|
|
|
I actually appreciate them moving the Start menu more to the center, because my screen is GIGANTIC, and I don't want it in my peripheral vision area.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I was talking about the option to dock left or right. They could have just added an option to the old menu to center it as you like, and improved the menu that way. But doing so wouldn't have satisfied their hubris, I guess...
|
|
|
|
|
Must be your Copilot giving you a helping hand? 
A home without books is a body without soul. Marcus Tullius Cicero
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
Except windows did this before copilot too, although it does seem to do it more now.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Is this because windows is using it as virtual memory to save writes to the NVMe drive?
That would at least make some sense, even if it is not quite what you want.
|
|
|
|
|
No.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
seems to me that I can disable drives in BIOS (or whatever Dell calls it these days), under the heading "Drives".
YMMV
>64
It’s weird being the same age as old people. Live every day like it is your last; one day, it will be.
|
|
|
|
|
I couldn't find the option to actually disable it in my bios settings. And yeah, I tried advanced mode. It lets me reorder them, and even SMART scan them, but disabling is apparently a league too far.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
So, I have dusted off my project yet again. Written in FORTRAN my goal is to lift it to modern systems. I've asked various questions over the years, but I hope this might just be my last hurrah that pays for the sailboat I want and pay off my mortgage. I also want to pull in some coder whannabees from local high schools (but that is VERY tbd).
Digging into this - my experience says the biggest issue with the existing system is that it's a big blob. I'll leave it there. I don't want to get into too much detail and vector my question.
In doing my research, I know I want to use C# to implement the initial UI. What I've concluded is that C# is the tip of the Microsoft iceberg. A language is a language - you just need to get familiar with it's quirks. But underneath C# is the mass of .net. Just like mfc, com, com++, dcom, ActiveX and all of the other rot MS pukes out. Don't get me wrong, some of it is okay. But it seems C# is the trivial part.
Am I on the wrong trail, or have I got this right?
Charlie Gilley
“Microsoft is the virus..."
"the problem with socialism is that eventually you run out of other people's money"
|
|
|
|
|
Are you asking if you need to become familiar with the P-code that C# emits, in order to create your solution? I don't understand the question the way it is worded.
|
|
|
|
|
no. I do not want to even know about p-code. What I'm saying/asking/spewing is it seems C# is just the basic tool to get into the .net framework. The analogy I would make would be hey I want to write a C++ interface with MFC. I don't want to do it in win32.
Stage 1 is to learn pure C# and stage 2 is to embrace the .net framework.
If I have to go into p-code, I've done something wrong.
Charlie Gilley
“Microsoft is the virus..."
"the problem with socialism is that eventually you run out of other people's money"
|
|
|
|
|
A small remark slighly on the side:
I never before heard dotNet IL (Intermediate Language) referred to as "P-code".
The term "P-code" was made famous by the Pascal compiler of 1970 (or thereabouts), generating code for execution on a virtual machine. Writing an interpreter (i.e. the virtual machine) for the Pascal P-code was quite simple; there were interpreters for dozens of machine architectures. The version that became prominent was called P4; it was the 4th version of P-code for the original Pascal compiler.
I even believe that some people replaced the microcode of the LSI-11, the single chip version of the PDP-11 architecture, with alternative microcode to interpret P4 directly without the need for an interpreter - but if my memory is correct, this solution was slower than the interpreter running on the LSI-11 with the original microcode and an interpreter on top 
P-code, or "bytecode" in general, is designed to be treated as the instruction set of a virtual machine, executed "as is".
dotNet IL is certainly not meant for execution as is on a virtual machine. I will not say that it is impossible, but it most certainly is pointless and extremely inefficient. IL is not a P-code or bytecode, but "source code" for the jitter - the Just In Time code generator, translating IL into native machine code for whatever CPU the jitter is run on, immediately before execution.
This probably is not at all significant to the OP. Maybe he will later get in touch with dotNet IL. When/if that happens, he should not believe that IL is interpreted the way P-code is.
End remark:
P-code/bytecode interpretation is certainly slower than native code, in some circumstances a lot slower. With C# - and all other dotNet languages - having the jitter generating native code, it had a speed advantage over Java, which used to interpret Java bytecode. You could compile Java to native code from the beginning, or at least very early, but then you got a binary that couldn't execute on any other architecture, and couldn't utilize e.g. optional instructions available on a specific machine. Java byte code could be moved freely around to any machine with an interpreter.
To be able to compete with C# on speed, the JVM (Java Virtual Machine) was extended with the capability of rather than executing the byte code as is, it started out by processing the byte code further, into native code for the current machine. This improved the execution speed significantly. However, Java bytecode wasn't designed for this use, and a lot of useful information for generating efficient machine code has been thrown away (as the machine code already has been generated, although for the virtual machine!) So in the general case, the dotNet jitter is in a much better position to generate optimal code, with much more information available.
After Java began processing its bytecode into native code before starting execution, lots of other bytecode based systems have followed, processing their bytecode to native code before execution.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
That's not how I see it.
As a poor analogy, I might say that the language is the fuel for running a vehicle (a UI framework).
Learning to operate the vehicle is the important part.
|
|
|
|
|
You are correct the C# component of .net is a minor part of the ecosystem and not something I would concentrate on YET.
Assuming there is a database component you will need to understand that. EntityFramework is one option (and a large one) or normal connections.
You need to decide on a UI, winforms, WPF or web. Choose the web and you open an entire bucket of worms and other nasties. WPF has a steep learning curve and winforms is somewhat dated.
You can then use your exploring these components to get your head around C# - the bits you need.
Now that is going to keep you entertained for some time. Although your experience will shorten the learning curve dramatically.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Mycroft Holmes wrote: winforms, WPF
Or WinUI; or MAUI; or Avalonia, if you're open to third-party stuff.
Mycroft Holmes wrote: web
Which has even more choices to make: MVC, Razor Pages, Blazor (Server), Blazor (Web Assembly), Blazor (Hybrid), ...
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
To answer your question, C# is just a language. .NET provides the runtimes (the CLR) as well as a target execution environment (the CLI). A C# compiler produces code that relies on the CLR the way that C program might rely on the C standard runtimes. However, like C, C# actually doesn't need the runtimes. I was mistaken about this myself at one point. I didn't know how it would collect garbage without them. Turns out C# doesn't indicate garbage collection, or really any memory management. That's on the runtimes. In that way, it's not really different than C (malloc), but a bit different than C++ (new/delete). I don't know how C# bakes out "new" in the standard specifically - i haven't looked, but I don't think it says it must be implicitly collected.
C# does not need to target the CLI either, and I believe there are toolchains out there that compile C#, sans garbage collection and the CLR/CLI, to a native machine target.
So C#, truly is just a language. But you'll almost never see it in the wild without .NET backing it up.
As far as learning curve, C# is simple, but the CLR had when I checked back in the .NET 1.0 days, 6500+ base classes in it.
So there's your learning curve.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
modified 14hrs ago.
|
|
|
|
|
thank you for confirming my fear/understanding/anticipation.
Charlie Gilley
“Microsoft is the virus..."
"the problem with socialism is that eventually you run out of other people's money"
|
|
|
|
|
You know where I think you'll start to really get hammered?
The user interface.
After Winforms it seems like Microsoft lost their way. They did away with RAD design and the ability to roundtrip between designer and code. WPF just isn't as friendly to drag and dropping UIs together and then refining in code the way Winforms was.
Worse, now there are so many platforms and offerings, what do you even use? MAUI? AvaloniaUI? raw WPF?
Personally I'm kind of partial to the idea of Electron. I think? Microsoft uses it to power VS Code, and if so, it's really impressive, but it's not .NET. I'm sure it can talk to .NET though.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
C# is just another language - albeit a good one - a competent developer can probably pick up most if not all of it in a day without much stress - the only complications are OOPs and references as compared to pointers or memory addresses. But once you have cracked that and if you are even slightly familiar with Windows development it'll be relatively easy to get started.
If you are only familiar with a procedural approach rather than message driven then it's going to take rather longer!
But ... C# on it's own won't help if you want to write a UI as it's all about the controls you can drop on the dialog (or Form as it's known) - there is a very wide set of those which have properties, events, and methods that you need to be aware of in order to use.
I'd suggest that a book (all the major players do good ones) that starts from scratch with C# and windows / .NET development would be worth the investment - it'll teach you C# and .NET at the same time, plus it'll cover most of the "bits and pieces" that you will probably want to use later on. Diving into VS and trying to work it out on your own is a recipe for disaster (but still better than YouTube tutorials) 
Good luck!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
everybody?
I hope that the users aren't now abandoning this place. 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Yah, no one good or smart comes here any more. <==== (edit: This is a joke!)
I'm still here most days. 
Here's my TLDR;
My wife was downloading photos from iCloud (iphone) so she could print them.
Discovered that 9/10 photos she downloaded were downloaded as zip files.
Apparently a lot of her photos were on "live photo" which includes a "video" portion.
So, when you take that photo and download from iCloud you get a zip which contains the .MOV and the JPEG.
We just want the JPEG so she can print some pix.
I wrote a .NET Core console app that:
1) allows user to point at directory where all those zips (100 or more) are and will pull out every JPEG and save them all into <target> folder provided by user
2) Run another command on the app and it'll tell you if any of the images are duplicates.
I'm really excited by this little utility because it is really cool and has a lot of uses.
You can use it to tell you if you have any duplicate files. It runs SHA256 hash on every file and then tells you if any two files are dups. 
The CP Problem
See how excited I am to talk about this?
This would normally become a CP article. But  should I do now?
Bummer 
|
|
|
|
|
Sounds like a nifty utility! Does it also remove the duplicates?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote: Does it also remove the duplicates?
Not yet, but I am going to add a switch the user can provide to do that too.
Oh, you can see the (very quickly written code) at my github: GitHub - raddevus/iPhotoGrabr: Unzips photos from iCloud downloads (.NET Core 8)[^]
Hope you can use it too.
I also build the EXE as a standalone for win10 (though I'm dev on Linux) to make it easier to use on my wife's win11 machine.
Take a look at the buildForWin10.sh (shell script) You can use the command in that file to build on Win10/11 too.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
