Development environment...

As I have said before, I'm taking a 'sandbox' PC back to Windows 10.

I decided it would be a good opertunity to play around with the development environment and thought it would be nice to get suggestion for tools, add ins, etc. that people find useful.

At the moment my main IDE is Visual Studio Enterprise 2019 and I'll be setting up WSL2 with Ubuntu-20.04 and Windows terminal.

Along with Windows desktop development, I'm also wanting to get back to embedded development, so will be wanting to tinker with Arduino, Raspberry Pi, Beagleboard etc.

I'm looking at vcpkg and/or conan for installing libraries and I need to learn how to use git and github properly, rather than the half-arsed way I do it for my own use.

So any suggestions?

PS. Thank you in advance.
I have one repository on GitHub whose only purpose is to keep development environment setup for various IDE's, languages and operating systems + project templates and build systems for various popular libraries.

What I want to say is that setting DE every time from scratch (ex. after OS reinstall and similar) would be too much of pain and a lot of time wasted.

Therefore, my first recommendation for you is to create a new repository, name it "DevEnironment" or something like that.

Then as you set up various dev. environments make sure you export your setups, templates projects, template source files, shareable configuration etc. into your DevEnvironment repo and push to remote.

Make sure you organize your repo according to IDE, language, OS, library etc.

This way you save a lot of time, you can keep track of changes so if you later misconfigure something simply look at git history to revert or update your dev. env. as needed.

This is how you maintain perfect build system.

----

Now, to answer your original question, what language will you use for what you're aiming?
and what kind of programs are you planning to write?

Just saying "I need dev environment" is not clear, this is first step, to say what you want to do, what kind of development, and in which programming language...
(You already shared some of this info, but in what languages?)

You have surely heard someone say "I'm not on development machine right now", or "I'm not at home near my dev machine" and similar.

Some people usually mean that dev. machine is some powerful computer, but in fact this also means dev machine has necessary environment set up that let's you compile anything you wish with minimum errors and as little work as needed.

Such setup takes time, that's why it is important to have one repo dedicated just for that.
In an ideal world dev. machine should be a separate computer or same computer but different user account, for security reasons and to keep it clean.
Last edited on
Hi malibor,

Until recently, I had spent 20 years as the sole developer in a small companies R&D department. As a result, I'm a little bit myopic in my development processes. So I thought that rather than just import my normal settings, I'd take this opportunity to have a look at what else is available...new tricks for an old dog.

Language wise C++14/17/20, probably C#, and C. I lost track of C++ when I had to learn C# and .net so I'm refreshing that. I want to move away from C# but may look at managed unmanaged interoperability or IoT stuff if I get around to looking at Azure Sphere. C because it still seems to be the de facto language for embedded systems.

What type of programs am I going to write? There is no straight forward answer to that. Apart from lots of practice code for the languages, investigations into the current state of the various windows API, and what I outlined here: https://www.cplusplus.com/forum/lounge/279606/#msg1208196 I guess broadly utilities/systems programming but I'll see were I go.

I have a few idea for some personal projects that I want to do:
* A Blood Bowl style of game. Not really into game dev but the AI for an opponent would be interesting.
* Software Defined Radio (SDR). I have an RTL dongle.
* Logic/Bus Analyser. I was given a FPGA board (Mojo v3, Spartan 6 and a high performance ATmega32U4 microcontroller) that may be useful.

I also have to check out the local job market and get something going for a portfolio...getting past the HR gatekeepers is a pain.

OK basically C and C++, it's good you don't push for more languages like you push for many different kinds of projects and research areas which isn't good.

Iot, systems programming, AI, drivers, Windows API, UI, games etc.. this is a cake too big to eat alone!

I suggest you narrow this down to either much less learning area, or to follow a list that you will then follow in order.

Here is an example roadmap to follow in order without skips:

1. Standard C++ up to C++20
2. Windows API starting with UI (excluding networking, cryptography, Audio and DirectX)
3. Basics of assembly programming
4. Basics of driver programming
5. Audio programming using MF (Microsoft media foundation, which is part of Windows API)
6. Direct 2D (excluding Direct 3D)

From that point you have 2 paths to choose from, which ever you choose stick to it!:

1. low level programming
- grasp assembly and driver programming to the full extent
- Learn reverse engineering
- Learn how to develop system service

2. game development
- 2D game development
- Learn DirectX and 3D
- make very simple game engine
- AI programming (btw. you need to be math professor to write good AI)
- Choose your game engine and stick to it, it will take time to learn it.
- Once you learn how game engine works, you'll know how to write your own, but not before.

If you can't choose your path, then learn:
- Cryptography
- Networking
and try to chose again what you want.

Development environment,
For C\C++ all you have to do is install VS choose "Desktop development" preset and it's all set, there is nothing more you need to start sample roadmap above.

If you want to skip straight to either of the 2 paths then there could be a long and hard to set up dev. environment, so I'll skip that part until you make your decision.
Last edited on
on windows, the things I have to have are small but they do what I want and need.
- a hex editor. One is much like another.
- notepad++ because visual studio removed the macro support, and this program does it exactly like old VS did
- cygwin ... because I use a handful of the command line tools, esp grep but others as well. Its g++ offers a different view of warnings, errors, etc than VS.

the other things I have are job specific, stuff I had to download for whatever reason.
Windows API starting with UI (excluding networking, cryptography, Audio and DirectX)

Does that exclude GDI and GDI+ usage as well? I know how much MS is deemphasizing using either in favor of DX. Including D2D.

Is there a modern MS 2D drawing framework other than D2D? I sure don't know of one.

Not that as a self-taught hobbyist I've really had the time or desire to go a-lookin'. Keeping up with C and C++ with their updated standards, c17/C++20, is about all I can do.
- a hex editor. One is much like another.


I often asked my self what's the purpose of a hex editor and do I need one?
Because we have one integrated into WinDbg (except it's called "memory")

Is there anything useful you can do in hex editor beyond changing some bytes?
Last edited on
RE: the usefulness of a hex editor.

From what I've read a hex editor is now mostly useful for hacking game executable and game save files.

Not that there aren't likely other uses, I have several hex editors installed on my main development machine and never had any real use for them.
Does that exclude GDI and GDI+ usage as well? I know how much MS is deemphasizing using either in favor of DX. Including D2D.

In my opinion, yes because almost any individual that is self taught (like most of us) doesn't have enough time to learn everything, and likely not enough money to pay for instructions on daily basis, especially something that is no longer encouraged, in MS case, there are many API's that are considered deprecated or no longer updated.

Some MS modern API's like MF and Bcrypt made their ancestor API's completely go out of scope. those new API's are not backward compatible, so why would you use or lean old API's then? isn't that a waste of your learning time?

There is a good statement which says that we should use only new API's in new projects and adapt to new way of writing code. (that excludes old code written a decade+ ago)
Not only MS says that, but also B. Stroustrup says we should run away from vintage way of writing code, and many other people say so as well.
Last edited on
I'd have to disagree with no GDI since the act of writing text to the client area is part and parcel of the GDI. It isn't just about drawing shapes and lines and painting the screen with pretty colors.

Can't draw text, why bother mucking around with the WinAPI.

Now, GDI+, that's whole 'nother bunny with a pancake on its head.....
You can draw text with direct write.

And if you find out that text is not consistent with text of other GDI based controls (ex. common controls) there is a CreateGdiCompatibleTextLayout that will make it look just like GDI drawn text.

https://docs.microsoft.com/en-us/windows/win32/api/dwrite/nf-dwrite-idwritefactory-creategdicompatibletextlayout

That's just 1 function, DX\DW has many more that do it GDI way, for example CreateDCRenderTarget let's you draw to GDI device context.

https://docs.microsoft.com/en-us/windows/win32/api/d2d1/nf-d2d1-id2d1factory-createdcrendertarget

There is almost nothing in GDI or GDI+ that you can't do with DX.
First you argue no DX, no GDI/GDI+. Now you end up arguing FOR all three.

I merely said not learning GDI as part of a well balanced WinAPI "learn from scratch" strategy isn't as well rounded as it should be. Putting text on the screen is a vital part of more than a few apps.

And maybe I'm just being more than a bit of a devil's advocate contrarian.
First you argue no DX, no GDI/GDI+. Now you end up arguing FOR all three.

Nowhere did I say that,

I'm saying there is no need to use or learn GDI because almost all of it can be done with DX.
You can draw text without GDI just fine.
Is there anything useful you can do in hex editor beyond changing some bytes?

What I use it for more often than not is verification of binary file read/write or actual format vs the documentation. I very rarely actually edit these days, so its really a 'hex viewer' in that sense. It was vital for a recent project I did importing a very complex binary file (3rd party).

That silly image hack I did in the other thread was GDI. DX can't open and save out image format inherently that I know of. But, I still do not know a darn thing about GDI. I just fiddled with the internet for an hour and glued it together. It seems screwy, but not difficult. Same as anything made by MS. If you are not doing something off the beaten path, you can just copy paste your way to a GUI from the web :)
Last edited on
Topic archived. No new replies allowed.