Recent Posts

1

Using Code::Blocks / new project wizard fails to locate glfw3.h

« Last post by Vigor on Today at 01:54:44 am »

This was not a problem before I installed the 13493 nightly build.

I now have 2 installations of codeblocks on my computer, one residing at the default location, the other residing where I unzipped the nightly.   

But that is fine, the nightly installation works great for my old projects and they get their .h .dll .a .lib files from the path to them from the old installation of codeblocks.

The default path of the new nightly build installation's wizard uses the old installation of codeblocks files.   That seems strange but the files are there so, I'm not bothered.   The problem is it keeps failing to find glfw3.h which, in the past resided in a GL\ directory inside the MINGW\include\ directory.   I also tried copying the
opengl files to the respective directories in the new installation and using the MINGW64 directory of the nightly installation but that didn't work either.

I found an old post where this was an issue 6 years ago and tried to follow the instructions to fix it
https://forums.codeblocks.org/index.php?topic=22850.0 but it doesn't appear to be exactly the same issue.  I think that old problem is fixed in this version but my problem is just similar.  I went to edit the script for the new project but the line numbers are different.  I think i found the appropriate lines of code but they already look right.   I don't know what to change or how to change it.   Perhaps this function shows the right place?

Code

function GetFilesDir()
{
    return _T("glfw/files");
}

Might that mean that I need to make a folder \MINGW64\INCLUDE\GLFW\FILES\ and ..\LIB\GLFW\FILES\ etc or would all of the gl files, .a .lib .dll go in one MINGW64\GLFW\FILES\ folder?    Is there even supposed to be a FILES\ folder or does the "files" in "glfw/files" act as a wildcard for files in a GLFW\ folder?

I also tried making an empty console application and converting it to a glfw3 application but that didn't work either, it said glfw3.h was missing at compile time.

In my previous/first installation of codeblocks, making a glfw project used glfw.h and I had to alter
each new project to make it a glfw3.h project.

I also tried moving all opengl .h .dll .a .lib files to the MINGW\ and MINGW64\ directories but that didn't work either.

I think i might be inclined to put all of the glfw3 files in one place to avoid needing a bunch of different paths but...   I suspect the solution to my problem is simple but arbitrary and i am unlikely to figure it out on my own.

Thank you for codeblocks and thank you for your time

2

Plugins development / Re: Code completion using LSP and clangd

« Last post by MaxGaspa on Yesterday at 10:43:40 pm »

Video linked from my google drive

https://drive.google.com/file/d/1AkwcYDVfGzkcidiqIOcD7T3ZZU4wHxom/view?usp=drive_link

Hope this helps

Max

3

Plugins development / Re: Code completion using LSP and clangd

« Last post by MaxGaspa on Yesterday at 08:05:51 pm »

Would you please give steps to re-create and trace the problem, i.e.,
1) do this
2) now do that

1) open a project with multiple source file, so the whole parsing process takes time (more than few seconds)
2) During the parsing process open a source file
3) Select in the box (shown in the attached e-mail) a choice
4) When the parsing of a file is completed the box is cleared (made empty).

In case I can make a video....

Max

4

Plugins development / Re: Code completion using LSP and clangd

« Last post by Pecan on Yesterday at 06:37:58 pm »

Hi,

I'm writing to submit a (passible) bug report of the Code Completion plugin (LSP and Clangd).

When I load a project the plugin starts to parse all the project's files. I observe the log of parsing in the Code::Blocks  panel of the Logs window. In the meantime  I open a file, Application.cpp for example,  and  I select "Application:" to use the plugin (see image attached)...but...as soon as a new file is parsed the selection disappears....so I can't use the code completion till the full parsing of the projects. As soon as a new file parsing is completed the selection becomes blank.

Is this behavior expected?

Windows 10 , latest nightly , latest Mys2 clang 18.1.3-1

Would you please give steps to re-create and trace the problem, i.e.,
1) do this
2) now do that

5

Plugins development / Re: Code completion using LSP and clangd

« Last post by MaxGaspa on Yesterday at 12:02:56 pm »

Hi,

I'm writing to submit a (passible) bug report of the Code Completion plugin (LSP and Clangd).

When I load a project the plugin starts to parse all the project's files. I observe the log of parsing in the Code::Blocks  panel of the Logs window. In the meantime  I open a file, Application.cpp for example,  and  I select "Application:" to use the plugin (see image attached)...but...as soon as a new file is parsed the selection disappears....so I can't use the code completion till the full parsing of the projects. As soon as a new file parsing is completed the selection becomes blank.

Is this behavior expected?

Windows 10 , latest nightly , latest Mys2 clang 18.1.3-1

6

General (but related to Code::Blocks) / Re: Relocatable Code

« Last post by Miguel Gimenez on Yesterday at 11:03:04 am »

Stupid bot trying to spread a trojan.

EDIT: It is a verbatim copy of this post in the MASM forum, and a future spam holder.

7

General (but related to Code::Blocks) / Relocatable Code

« Last post by ramiroflores on Yesterday at 08:48:41 am »

Hi
I updated a project originally developed by Bryant Keller and later developed further by Homer and me. It's about code that can be placed anywhere in memory (relocated).
The basic trick used here is that all addresses are relative and everything is in a single writable and executable segment. The addresses of the APIs used are read from the loaded DLL images. The code used for this cannot initially access any DLL, so it must be included.

The purpose of this technique is to send code from one computer to another to realize distributed computing. There are many alternatives, but this is one of the fastest.

To demonstrate this technique, I first wrote and then executed the relocatable code on a standard Windows Shared Memory Object (SMO). The code doesn't do much. After it has loaded and parsed all the required DLLs it displays a simple dialog box. The title bar contains the ProcessID and, if applicable, an asterisk after it. The latter only appears if the SMO was required to be written. However, if the asterisk does not appear, the code could be executed directly from memory by another existing instance.

To see this, you simply need to launch the .EXE file several times. Super cool!  :cool:

I have now added support for 64 bit and WIDE strings.

With the current version of DebugCenter you can watch what the remote code is doing over the network, but that's another story.

Code

; ==================================================================================================
; Title:      Relocatable.asm
; Author:     G. Friedrich
; Version:    C.1.0
; Purpose:    Demo code to create a Shared Memory Object, inject some relocatable code into it,
;             execute the relocatable code within the SMO, throw a MessageBox to prove its
;             working / hang the app instance, and finally return to the Caller.
;             K32B.inc first written by Bryant Keller, 2005 and
;             modified by EvilHomer, 2005 (100% Relative, no hardcoded addresses generated)
; Notes:      Version C.1.0, November 2023
;               - First release.
; ==================================================================================================


% include @Environ(OBJASM_PATH)\Code\Macros\Model.inc
SysSetup OOP, WIN64, WIDE_STRING;, DEBUG(WND)

% include &IncPath&Windows\winternl.inc                 ;Required for RelocCode.inc

MakeObjects Primer, SharedMemoryObject


;===================================================================================================

;Important notes:
;  Our Remote CodeBlock has three important labels:
;    - RelocCodeSTART defines the beginning of the codeblock
;    - RelocCodeENTER defines the entrypoint in the codeblock
;    - RelocCodeSTOP  defines the end of the codeblock
;
;  RelocCode.inc MUST be included in the remote code block. It contains a relocatable version of
;  GetProcAddress, as well as a bunch of handy macros for writing relocatable code.
;  It doesn't have to be the first thing in the code block, but it MUST precede any references to
;  its macros.
;
;  The $Delta macro returns the ADDRESS of label, not data stored there

SHARED_SIZE equ PAGESIZE
TypeRelocEnter typedef proto :DWORD

.code
RelocCodeSTART:
include RelocCode.inc

pBaseNTDLL POINTER  NULL    ;Base address of NTDLL.dll
pBaseK32   POINTER  NULL    ;Base address of Kernel32.dll
pBaseU32   POINTER  NULL    ;Base address of User32.dll
hLibU32    HANDLE   0       ;Library handle of User32.dll

USE_API GetModuleHandle
USE_API LoadLibrary
USE_API FreeLibrary
USE_API MessageBox
USE_API GetCurrentProcessId
USE_API wsprintf

String szUser32,  "User32"
String szCaption, "How cool is this? Caller's Process ID = %lu  %c"
String szMessage, "I'm executing from within a Shared Memory Object.", CRLF, \
                  "You can fire up simultaneous instances if you like."
szBuffer  CHR  256 dup (0)

RelocCodeENTER proc uses xbx, cMarker:CHR         ;This is our relocated entry point
  GetDllBases pBaseNTDLL, pBaseK32

  ;Prepare a few common API functions
  LoadApi pBaseK32, GetModuleHandle
  LoadApi pBaseK32, LoadLibrary
  LoadApi pBaseK32, GetCurrentProcessId

  ;Gain access to User32 to be able to call "MessageBox"
  ApiRelCall GetModuleHandle, $Delta(xcx, szUser32)
  .if xax == NULL
    ;Load User32.dll
    ApiRelCall LoadLibrary, $Delta(xcx, szUser32)
    ;Remember that we had to LOAD this DLL
    SetDelta hLibU32, xax, xbx
  .endif
  SetDelta pBaseU32, xax, xbx

  ;Prepare MessageBox and wsprintf
  LoadApi pBaseU32, MessageBox
  LoadApi pBaseU32, wsprintf

  ;Grab the current Process ID
  ApiRelCall GetCurrentProcessId

  ;Format a string with PID
  ApiRelCall wsprintf, $Delta(xcx, szBuffer), $Delta(xdx, szCaption), xax, cMarker

  ;Perform MessageBox
  ApiRelCall MessageBox, NULL, $Delta(xdx, szMessage), $Delta(xax, szBuffer), MB_OK

  ;Unload User32 if required
  .if HANDLE ptr [$Delta(xbx, hLibU32)] != 0
    LoadApi pBaseK32, FreeLibrary
    ApiRelCall FreeLibrary, HANDLE ptr [xbx]
  .endif

  ;Return to Caller
  ret
RelocCodeENTER endp

RelocCodeSTOP:


;===================================================================================================

start proc uses xbx xdi
  local pSMO:$ObjPtr(SharedMemoryObject)

  SysInit

  mov ebx, ' '                                          ;Reset marker
  mov pSMO, $New(SharedMemoryObject)
  OCall pSMO::SharedMemoryObject.Init, NULL, $OfsCStr("SharedMemoryCode"), SHARED_SIZE, \
                                       FILE_MAP_EXECUTE or FILE_MAP_WRITE
  .if eax != FALSE
    mov xcx, pSMO
    mov xdi, [xcx].$Obj(SharedMemoryObject).pMem
    .if eax == SMO_OPENED_NEW
      DbgClearAll
      ;We just created a NEW SMO. copy our codeblock into it
      DbgText "Writing relocatable code to SMO"
      invoke MemClone, xdi, offset RelocCodeSTART, (RelocCodeSTOP - RelocCodeSTART)
      mov ebx, '*'                                      ;Set marker when SMO was written
    .endif

    ;We're ready to execute our codeblock
    DbgText "Executing relocated code"
    ;Calculate the address of RelocCodeENTER in remote code block and CALL to that location
    add xdi, (RelocCodeENTER - RelocCodeSTART)
    invoke TypeRelocEnter ptr xdi, ebx
    DbgText "Returned from relocated code"

  .endif

  Destroy pSMO                                          ;Unmap SMO from this app instance
  SysDone                                                  ;It is only released once it has been
  invoke ExitProcess,0                                 ;released by all applications that
  start endp                                                ;have opened it.

end

Attached is the 64 bit .EXE file.

Have fun!

8

Help / Re: problem with silent install in version codeblocks-20.03mingw-setup

« Last post by ollydbg on Yesterday at 04:13:24 am »

Hi, this image is too small that nothing can be seen from it.

I suggest using a nightly version of Code::Blocks, and this version don't need to be "installed". You just need to "unzip" the extracted zip files.

About the compiler, you need to install a compiler, for example:

[WinLibs - GCC+MinGW-w64 compiler for Windows](https://winlibs.com/)

9

Help / problem with silent install in version codeblocks-20.03mingw-setup

« Last post by olivier sc on April 15, 2024, 08:40:15 pm »

Hello dear,

I try to install silently codeblocks-20.03mingw-setup.exe with /S
I get alwais a exit status 2
When i lunch it, no compiler is present.
You can see attached image:
in 1 it is a machine that has never had codeblock installed.
in 2 it is a machine installed by hand or having already had codeblock installed

I see this on chocolatey package to!

10

Using Code::Blocks / Re: Compiler Settings: limited to C++ 14 standard

« Last post by nenin on April 15, 2024, 07:25:57 am »

You can directly introduce any options supported by compiler in "Other compiler options". "Compiler Flags" is outdated and missing some important flags like "-march=x86-64-v2" [/b]

oh, I see
I wonder if this should be reported as a bug somewhere

In nighties I have standard support up to C++ 2020 and C 2017. But there are so many other flags for the the GCC...