DEV Community: estrolabz

https://www.youtube.com/@ESTROLABZ

https://autumn-oboe-c16.notion.site/ESTROLABZ-Blog-237763e1ef908090a5fec3ea8c04331e?source=copy_link

WHY ARE WE STILL BUILDING APPS ON INSECURE FOUNDATIONS?

estrolabz — Tue, 29 Jul 2025 22:58:26 +0000

YouTube Channel: https://www.youtube.com/@ESTROLABZ

DAY 02 - From Code to Canvas: My SDK Renders Its First Window (OpenGL)

estrolabz — Tue, 29 Jul 2025 03:42:18 +0000

I'm building a high-performance C++ SDK for making native, OpenGL-accelerated Windows apps — with security and modularity in mind.

Recap

Hello everyone and welcome back to another devlog! Yesterday we managed to setup the project and get everything working ready to start creating a window with an OpenGL context. We managed to create our project structure (Lib / DLL) ELBZ and (Test App) called TestLab then create our application and entry-point ready for use when we use ELBZ to create real-world applications.

If you have not seen the last dev log here is a link:

DAY 01 - I setup my SDK Project and Created the Entry Point!

Todays Objectives

Create a Windows Window Natively
Setup Glad as a Static Library
Create an OpenGL Render Context with OpenGL 4.6
Change the background screen to be another colour (Proves OpenGL is working!)

Progress

Creating the Native Window in Windows

So today I started by creating a simple header file with my window class structure like this:

class Window {

public:

    Window(const wchar_t* _title, unsigned short _width, unsigned short _height);
    void Run();
    ~Window();

private:
    void* window_instance = nullptr;
    void* device_context = nullptr;
    void* render_context = nullptr;
    const wchar_t* title;
    unsigned short width = 400;
    unsigned short height = 200;
};

I decided to have three void pointers for storing important links to different aspects of the window that I may need to keep track of for the future.

I also decided to just take a title, width and height for the window for now as that is all I really need for this current moment in time.

As for the functions I am using a init, run and shutdown sequence of code. The constructor is the init method, the run is the run and the de-constructor is the shutdown method, used to handle the life cycle of the native windows window system.

Adding Default OpenGL Context

Next I added the default OpenGL Context to my window which resulted in this:

// Render: clear black
glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

Fantastic its working!!!!!!

As you can see I have successfully got a window with OpenGL but… here is the thing this is using legacy OpenGL not modern OpenGL 4.6 so now its time to fix that.

Adding Glad to Enable Modern OpenGL 4.6

Adding glad caused quite a lot of headaches but after using different versions and figuring out why things don’t map correctly to each other I decided that I would create a new static library and link it to my dll and it seemed to fix my issue:

Now that I have created the new static lib I configured it with all the linking, defines build procedures etc…

Then after that I Generated the Glad Code for OpenGL 4.6 and WGL 1.0 - this was necessary because I was setting up a GL Context natively not using GLFW or SDL2 which means I needed to manually configure WGL to get OpenGL working with windows.

Setting Up the Modern OpenGL Context

Now that I had Glad fully working and setup I could use it to create the context for the native window to finally render graphics using Modern OpenGL.

I did this by firstly setting up a Pixel Descriptor, then setting it to the device context of the window then I had to create a temp context which is just to setup OpenGL and will be deleted after making it the current context.

Once that was done I could setup some attributes for OpenGL like setting the version I want to use etc…

Then I proceeded to create the context attrib arbs which just creates a gl context for me which will allow me to test OpenGL and ensure it is all working correctly.

Once that was done I could delete the temp context as it was not needed any more and create a new one which was my main context used for my actuall SDK.

Then I proceeded to check glad is loaded and working correctly and set the different pointers of the window class to be what I need such as device context and render context.

I also output some debug info to the screen just so that I could see some useful information such as:

OpenGL Version
OpenGL Renderer - which is the graphics card
OpenGL Shading Language Version

Configuring OpenGL On-Update

Now that the context was setup I could go to my main loop and set OpenGL background colour clear and swap buffers to ensure it actually renders on the window I want.

// Render: clear black
glClearColor(0.3f, 0.3f, 0.5f, 1);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

// Swap buffers
SwapBuffers((HDC)device_context);

With that the results are as shown here:

I successfully got a OpenGL window rendered with some debug info in the console for reassurance everything is working as expected! 😊

Final Thoughts

Conclusion

After implementing these features it was a little challenging at times but overall not too difficult and now I am more than every excited to start developing a 2D renderer and UI library etc… I cannot wait to make this SDK powerful with security, efficiency and practicality.

Tomorrows Objectives:

Add a OpenGL API Layer (Raw OpenGL Code)
Add a Graphics Render API Layer (Interfaces between all possible graphics apis and the renderer)
Add a Renderer 2D Layer (Allows things like creating rectangles on the screen something simple)
Create a Logger (I need the ability to log to the console more professionally and not just std::couts everywhere)

Support

This SDK is still early in development, and I’m not ready to charge for it yet.

But if you'd like to support development or get early access when builds drop, you can follow or join here: my Patreon

Contact & Other Socials

https://www.youtube.com/@estrolabzuk

https://autumn-oboe-c16.notion.site/ESTROLABZ-Blog-237763e1ef908090a5fec3ea8c04331e?source=copy_link

DAY 01 - The Entry Point to Everything

estrolabz — Mon, 28 Jul 2025 04:06:32 +0000

Recap

My last dev log was showing my progress of developing my SDK data type library, however after using that I noticed a lot of issues with it and decided to scrap it all together for now, I will explain why during this section.

I also decided to scrap my entire project and start again. The reason for this is that I was using premake5 as my build system and had a lot of issues with visual studio and getting everything working how I wanted. So I decided you know what I don’t need a build system I can just setup the project configuration on each platform that I need when I need to develop for it.

So, as for my data type library. I had issues with cross compatibility with using windows.h function data types which causes so much frustration and headaches I decided to just scrap it for now and focus on what matters, until I gain the knowledge and ability to create this library without these issues.

One of the reasons for making this decision to scrap my current work and start again was due to the fact that I could not get pre-compiled headers to work and link correctly using premake it constantly created more issues with my code and I just decided to do it all manually as it would be faster.

Lastly I realised that I should focus on making my code work before making it look pretty and efficient. So I actually realised the hard way that instead of spending months working on the little things I should just spend some time getting a working version of my project using the standard library in C++ and then one day once I have everything up and running and working I can go back and replace the standard library functionality with my own custom stuff which will also allow for better testing and ensuring it meets the exact requirements instead of guessing and having issues like I did with my data type library. It was not tested in the real application until too late and failed which resulted in taking too much time to fix or just scrap for now.

Todays Objectives

Today I plan to get my entire project setup manually using Visual Stduio 2022 on Windows 64-bit. To do this I need to complete the following objectives:

Create a Shared Library Project
Create a TestLab App Project
Create a Custom Configuration
Create a Pre-Build Step for TestLab
Create the Core Application Class

Progress

Setting Up the Initial Projects

ELBZ DLL Project

The first project I setup was ELBZ my shared library project which will power all software built with ELBZ.

TestLab Application Project

Next I created the TestLab Project which is an application that will allow me to test my ELBZ Library by calling functions and simulating usage of the SDK.

Setting Up the Core API Logic

Inside of the Core file will be all the core logic related to the SDK. This includes the API Define for determining if we should be exporting or importing a dll function/class.

ELBZ Project - `Test.hpp`

__declspec(dllexport) void Print();

TestLab Project - `Main.cpp`

__declspec(dllimport) void Print();

int main() {

    Print();

    return 0;
}

As you can see these two files show how in each project I access and use a function.

Now for my API Define - this is used to automatically decide if I need to import or export the function when including the header file form ELBZ.

`Core.hpp`

#pragma once

#ifdef ELBZ_DEF_PLATFORM_WIN64

    #ifdef ELBZ_DEF_OUT_TYPE_DLL
        #define ELBZ_API __declspec(dllexport)
    #else
        #define ELBZ_API __declspec(dllimport)
    #endif

#else
    #error ELBZ Only Supports Win64
#endif

ELBZ Project - `Usage.hpp`

#pragma once

#include "Core.hpp"

class ELBZ_API Test {
    public:
        void Print();
};

TestLab Project - `Main.hpp`

#include <ELBZ.hpp>

int main() {

    Print();

    return 0;
}

Creating the Entry Point

For the entry point I made my life a little easier I used a popular approach for this where the dll handles the runtime definition using a pointer to the function inside of the TestLab project to run the application here let me show you what I mean.

ELBZ Project - `EntryPoint.hpp`

extern Application* NewApp();

int main(int argc, char** argv) {
    Application* app = NewApp();
    app->Run();
    delete app;
}

TestLab Project - `App.cpp`

#include <ELBZ.hpp>

class TestLab : public Application
{
    TestLab() 
    {

    }

    ~TestLab()
    {

    }
};

Application* NewApp() 
{
    return new TestLab();
}

This here is a very common approach and I will be planning to change this later on as I have another idea of how I would like people to use the SDK to create an entry point, but for now this will stay like it is probably for a while as my plan is to just get everything working and then go back later and fix all the things that are ugly or not optimised enough.

Final Thoughts

Conclusion

After implementing all of this I am very happy to continue and build the next stage in this project. I am very excited for this project and I understand completely that a lot of this setup stuff before we get to rendering graphics will be similar to other software structures out there but my objective is to get things working as early as possible and then go back and change the structure if I need to for a more efficient one. So please be patient and hopefully we will have a working version of this SDK that we can use to develop some incredibly applications very soon.

Tomorrows Objectives

Create a Window using Windows.h
Setup an OpenGl Render Context with the Window
Link the OpenGL Library
Implement Glew for linking to modern OpenGl Usage

Feedback

If you do have any feedback or ideas you would like to discuss please feel free to contact me via an-means of communication through my socials I will respond as fast as I can.

Contact & Other Socials

https://www.youtube.com/@estrolabzuk

https://medium.com/@estrolabz

https://autumn-oboe-c16.notion.site/ESTROLABZ-Blog-237763e1ef908090a5fec3ea8c04331e?source=copy_link

Tutorial - How to create your own static library in C++ (WINDOWS)

estrolabz — Wed, 23 Jul 2025 22:05:42 +0000

Introduction

Hello everyone and welcome to my first ever tutorial! In this tutorial I will walk you through how to create your own static library project from scratch in C++ with Premake5.

We will be using premake5 as it allows us to write some lua code to configure our project and then create a build system for any platform we required to develop on. It is very easy to setup and this tutorial will cover it.

This tutorial will be done for windows 11 currently, however future tutorials on different operating systems will be release later on but for now windows is what this tutorial will focus on.

I will provide some references to other operating systems in case you would like to follow along anyways but if you come across issues they will not be directly supported in this tutorial.

Requirements

You must already have knowledge of what a static library is and when to use them.
Have Visual Studio 2022 installed correctly. (With C++ development addons)
Basic knowledge of C++ syntax
Using windows (Preferably), linux or macos.
Have a basic code editor installed such as vscode, sublime or something else.

Tutorial

Step 01 - Setting up our project directories

So the first thing we need to do is create a folder called whatever our project is for example I will call mine Static_Library_Project_Template .

Next we will need to open this folder in our preferred minimal code editor, for me this is vscode:

Once you have go to this stage we can create a number of folders ready to be used for our project, here is my recommended folder structure:

Static_Library_Project_Template
-> Build - This will be used to hold the premake5 binary executable.
-> Scripts - This will be used to hold the scripts to run the premake build 
   system creation for each platform (Windows, Linux, MacOS).
-> Libs - Holds all libraries in our project/solution
-> Apps - Holds all application in our project/solution

Step 02 - Setting Up our Base Configuration Files

Next we can create the base files in our root project directory:

Static_Library_Project_Template
-> Build-Solution.lua - This file is the premake5 configuration file for 
   creating our project buld system.
-> .gitignore - Include this file only if you are using git
-> README.md - Include this file only if you are using git

Lets go ahead and start writing our configuration file in lua, so to do this open your Build-Solution.lua file and write the following code:

-- Define a new workspace named "PROJECT_NAME"
workspace "PROJECT_NAME"

    -- Set the target architecture to 64-bit
    architecture "x64"

    -- Define 3 build configurations: DEBUG, RELEASE, and DIST (distribution)
    configurations { "DEBUG", "RELEASE", "DIST" }

    -- Specify the default startup project when the solution is opened
    startproject "Apps/DebuggerApp"

    -- Apply the following settings **only on Windows systems**
    filter "system:windows"
        -- Enable C++ exception handling using standard C++ semantics
        buildoptions { "/EHsc",
            -- Enforce use of standard conforming preprocessor
                       "/Zc:preprocessor",
            -- Ensure __cplusplus macro reflects the actual C++ language version
                       "/Zc:__cplusplus" }

-- Define a variable that sets the output directory pattern based on system, architecture, and config
OutputDir = "%{cfg.system}-%{cfg.architecture}/%{cfg.buildcfg}"

-- Start a new group in the solution explorer (grouping related projects)
group ""
    -- Include a Lua build script for a static library called StaticLibName
    include "Libs/StaticLibName/Build-StaticLibName.lua"

-- Return to root group (no name)
group ""

-- Include the build script for the DebuggerApp application
include "Apps/DebuggerApp/Build-DebuggerApp.lua"

So with this please not you can change the PROJECT_NAME to what your project is called. You can also change the StaticLibName to your library name. If you would also like you can change the DebuggerApp to your own custom name however we called it this as it will only be used for testing our library works which is the reason we are creating an Executable application in our library project.

So far you should have something like this:

Step 03 - Next we need to install and setup premake5.exe

We can download premake5.exe from the following link:

https://premake.github.io/download

Make sure that you download the version that is for your operating system.

Once downloaded we need to copy/move the premake5.exe file into our Build directory.

I have downloaded the file and it gives me a zipped executable file, so I will now unzip this and I will have the following:

Then we go into the extracted folder and find our executable:

This is the file we must copy / move into our Build directory in our project folder so lets go ahead and do that:

As you can see I have now moved this file into the correct folder and this is also what you should have too.

Step 04 - Windows Pre-Build Script

In this step we need to create the windows batch script that will run premake5.exe with our configuration to create our development environment based on our custom configuration.

Lets start with creating a file called Setup-Win64.bat in the Scripts Folder:

Now lets write some batch script code:

@echo off
REM Disable command echoing for cleaner output

pushd ..
REM Save current directory and change to parent directory

Build\premake5.exe --file=Build-Solution.lua vs2022
REM Run Premake5 to generate Visual Studio 2022 project files using Build-Solution.lua

popd
REM Return to the original directory

Perfect now you should have something that looks like this:

This is great but if we were to run this batch script now we would have an error: why is that? Well you see although we created the configuration file we actually need to create our static library project and Debugger App project with a configuration file in each of these projects for this to all work.

Step 05 - Create the Static Library Project

So lets start by creating a folder in our Libs folder called whatever it is we named our static library in our Build-Solution Configuration File.

For me that is StaticLibName.

As you can see I have created the folder called StaticLibName inside of the Libs folder.

Next we need to create another configuration file in lua called Build-StaticLibName.lua . And then we must make sure we have the following code:

-- Define a new project named "StaticLibName"
project "StaticLibName"

   -- Set the project type to a static library (.lib)
   kind "StaticLib"

   -- Set the programming language to C++
   language "C++"

   -- Use the C++23 standard for compilation
   cppdialect "C++23"

   -- (Temporary) set the output directory for binaries based on build config (e.g., DEBUG/RELEASE)
   targetdir "Binaries/%{cfg.buildcfg}"

   -- Use the shared C runtime (not statically linked)
   staticruntime "off"

   -- Add all header (.hpp) and source (.cpp) files from these folders to the project
   files { "Includes/**.hpp", "Source/**.cpp" }

   -- Include the "Includes" folder so headers can be found during compilation
   includedirs
   {
      "Includes"
   }

   -- Set final target output path using system, architecture, config, and project name
   targetdir ("../../Binaries/" .. OutputDir .. "/%{prj.name}")

   -- Set intermediate object files output path for compiled objects
   objdir ("../../Binaries/Intermediates/" .. OutputDir .. "/%{prj.name}")

   -- Apply settings only for Windows systems
   filter "system:windows"
       -- Use the latest available Windows SDK version
       systemversion "latest"

       -- Define a macro indicating the build is for 64-bit Windows
       defines { "DEF_WIN64" }

   -- Apply settings for the DEBUG configuration
   filter "configurations:DEBUG"
       -- Define a macro for debug builds
       defines { "DEF_DEBUG" }

       -- Link the debug version of the runtime library
       runtime "Debug"

       -- Enable debug symbols (for stepping through code in debugger)
       symbols "On"

   -- Apply settings for the RELEASE configuration
   filter "configurations:RELEASE"
       -- Define a macro for release builds
       defines { "DEF_RELEASE" }

       -- Link the release version of the runtime library
       runtime "Release"

       -- Enable compiler optimizations
       optimize "On"

       -- Keep debug symbols enabled (optional, for profiling/symbolic stack traces)
       symbols "On"

   -- Apply settings for the DIST (distribution/final product) configuration
   filter "configurations:DIST"
       -- Define a macro for final distribution builds
       defines { "DEF_DIST" }

       -- Use release runtime
       runtime "Release"

       -- Enable compiler optimizations
       optimize "On"

       -- Disable debug symbols to reduce binary size and hide internals
       symbols "Off"

Now we have this configuration file lets write some sample code for our library:

Firstly lets create two folders in the StaticLibName folder:

StaticLibName
-> Includes
-> Source

After that lets create two files a .cpp and .hpp file now the .hpp file will go inside the Includes folder and the .cpp file will go inside the source folder. The file should be named Add.hpp and Add.cpp .

`Add.hpp`

namespace MATH {
    int add(int a, int b);
}

`Add.cpp`

#include "Add.hpp"

int MATH::add(int a, int b) {
    return a + b;
}

Step 06 - Create the Debugger App Project

So lets start by creating a folder in our Apps folder called whatever it is we named our Debugger App in our Build-Solution Configuration File.

For me that is DebuggerApp.

As you can see I have created the folder called DebuggerApp inside of the Apps folder.

Next we need to create another configuration file in lua called Build-DebuggerApp.lua . And then we must make sure we have the following code:

-- Define a new project named "DebuggerApp"
project "DebuggerApp"

    -- Set the project type to a console application (produces .exe)
    kind "ConsoleApp"

    -- Use the C++ programming language
    language "C++"

    -- Use the C++23 standard for compiling the code
    cppdialect "C++23"

    -- Set a temporary target output directory based on build configuration
    targetdir "Binaries/%{cfg.buildcfg}"

    -- Link against the dynamic C runtime (instead of statically)
    staticruntime "off"

    -- Add all header (.hpp) and source (.cpp) files from these folders to the project
    files { "Includes/**.hpp", "Source/**.cpp" }

    -- Specify include directories for header file lookup during compilation
    includedirs
    {
        "Includes",                            -- Local project headers
        "../../Libs/StaticLibName/Includes"    -- Headers from the linked static library
    }

    -- Link this app against the "StaticLibName" static library
    links
    {
        "StaticLibName"
    }

    -- Set the final output directory for the executable (organized by OS, arch, config, and project)
    targetdir ("../../Binaries/"..OutputDir.."/%{prj.name}")

    -- Set the intermediate directory for object files during compilation
    objdir ("../../Binaries/Intermediates/"..OutputDir.."/%{prj.name}")

    -- Apply the following settings only when building on Windows
    filter "system:windows"
       -- Use the latest available Windows SDK
       systemversion "latest"

       -- Define a macro to indicate the build is for 64-bit Windows
       defines { "DEF_WIN64" }

    -- Configuration-specific settings for DEBUG
    filter "configurations:DEBUG"
       -- Define a macro to indicate a debug build
       defines { "DEF_DEBUG" }

       -- Use the debug runtime library
       runtime "Debug"

       -- Enable debug symbols for debugging in IDEs
       symbols "On"

    -- Configuration-specific settings for RELEASE
    filter "configurations:RELEASE"
       -- Define a macro to indicate a release build
       defines { "DEF_RELEASE" }

       -- Use the release runtime library
       runtime "Release"

       -- Enable optimizations for performance
       optimize "On"

       -- Keep debug symbols (optional for debugging or profiling)
       symbols "On"

    -- Configuration-specific settings for DIST (distribution/final release)
    filter "configurations:DIST"
       -- Define a macro to indicate a distribution build
       defines { "DEF_DIST" }

       -- Use the release runtime library
       runtime "Release"

       -- Enable full compiler optimizations
       optimize "On"

       -- Disable debug symbols to reduce binary size and improve load time
       symbols "Off"

Now we have this configuration file lets write some sample code for our library:

Firstly lets create two folders in the DebuggerApp folder:

DebuggerApp
-> Includes
-> Source

After that lets create two files a .cpp and .hpp file, now the .hpp file will go inside the Includes folder and the .cpp file will go inside the source folder. The files should be named Test.hpp and Main.cpp .

`Test.hpp`

#include <iostream>

void log_test(int res) {
    std::cout << res << std::endl;
}

`Main.cpp`

#include "Test.hpp"
#include <Add.hpp>

int main() {
    int result = MATH::add(5, 6);
    log_test(result);
    return 0;
}

Step 07 - Running our Pre-Build Setup and Testing

So now that we have set everything up go to a terminal inside the Scripts folder like this:

And type the following command:

.\Setup-Win64.bat

Press enter and you should see this:

Perfect now you can open the PROJECT_NAME.sln file and it should open this window:

We can now press the Local Window Debugger button with a big green arrow before it to run our solutions and see what happens.

Here is what you should get:

SUCCESS

If you get this then well done you have SUCCESSFULLY completed this tutorial and setup your first project with a static library. :)

Contact Information

https://www.youtube.com/@estrolabzuk

https://medium.com/@estrolabz