KolibriOS/kolibrios
15
25
Fork 61
Code Issues 133 Pull Requests 32 Actions Projects 1 Releases Wiki Activity

dll: add dll_LoadLibrary for single library loading #370

Merged
Burer merged 10 commits from hrigar/kolibrios:feature/dll-LoadLibrary into main 2026-05-04 19:03:52 +00:00
Conversation 15 Commits 10 Files Changed 3
+86 -64
hrigar commented 2026-03-15 12:58:11 +00:00
Contributor
Copy Link
Copy Source

Resolves #281

This PR adds a new dll_LoadLibrary function to dll.obj that loads a single library by name or full path, auto-calls lib_init, and returns the export table pointer.

dll_load is refactored on top of dll_LoadLibrary.

Resolves #281 This PR adds a new `dll_LoadLibrary` function to `dll.obj` that loads a single library by name or full path, auto-calls `lib_init`, and returns the export table pointer. `dll_load` is refactored on top of `dll_LoadLibrary`.
hrigar added 1 commit 2026-03-15 12:58:12 +00:00
dll: add dll_LoadLibrary for single library loading
Build system / Check kernel codestyle (pull_request) Successful in 1m18s
Details
Build system / Build (pull_request) Successful in 10m50s
Details
58457270c4 
Signed-off-by: hrigar <h4gar02@protonmail.com>
Doczom added the Category/LibrariesFASM
Kind
Feature
 labels 2026-03-15 13:12:53 +00:00
Doczom requested review from Doczom 2026-03-15 13:14:39 +00:00
Doczom requested review from dunkaist 2026-03-15 13:14:40 +00:00
Doczom commented 2026-03-15 13:17:02 +00:00
Owner
Copy Link
Copy Source

Add similar functionality to the /programs/dll.inc repository file. It should have the same functionality as the library.

Add similar functionality to the /programs/dll.inc repository file. It should have the same functionality as the library.
👍 1
dunkaist commented 2026-03-15 22:56:41 +00:00
Owner
Copy Link
Copy Source

Should dll.Load be rewritten to call dll.LoadLibrary in a loop? It looks like an unnecessary code duplication at the moment.

Should dll.Load be rewritten to call dll.LoadLibrary in a loop? It looks like an unnecessary code duplication at the moment.
hrigar commented 2026-03-16 22:08:48 +00:00
Author
Contributor
Copy Link
Copy Source

Currently dll.Load follows Load -> Link -> Init order sequence, but using LoadLibrary internally would change this to Load -> Init -> Link. We'd need to verify both orders produce identical effects.

Currently dll.Load follows Load -> Link -> Init order sequence, but using LoadLibrary internally would change this to Load -> Init -> Link. We'd need to verify both orders produce identical effects.
hrigar added 1 commit 2026-03-16 22:33:37 +00:00
Add dll.LoadLibrary proc to programs/dll.inc
Build system / Check kernel codestyle (pull_request) Successful in 1m18s
Details
Build system / Build (pull_request) Successful in 16m40s
Details
fde706a250 
Signed-off-by: hrigar <h4gar02@protonmail.com>
hrigar added 1 commit 2026-03-16 22:37:09 +00:00
Merge branch 'main' into feature/dll-LoadLibrary
Build system / Check kernel codestyle (pull_request) Successful in 2m1s
Details
Build system / Build (pull_request) Successful in 15m59s
Details
f196a41727
dunkaist commented 2026-03-16 23:58:04 +00:00
Owner
Copy Link
Copy Source

Currently dll.Load follows Load -> Link -> Init order sequence, but using LoadLibrary internally would change this to Load -> Init -> Link. We'd need to verify both orders produce identical effects.

Can we then have two commits? The first one as it is now, and the second one on top that changes the logic to call dll.LoadLibrary from dll.Load. This way, if anything breaks, we will just revert the second commit and that's it.

> Currently dll.Load follows Load -> Link -> Init order sequence, but using LoadLibrary internally would change this to Load -> Init -> Link. We'd need to verify both orders produce identical effects. Can we then have two commits? The first one as it is now, and the second one on top that changes the logic to call dll.LoadLibrary from dll.Load. This way, if anything breaks, we will just revert the second commit and that's it.
👍 1
hrigar added 1 commit 2026-03-18 12:44:40 +00:00
dll: refactor dll.Load to use dll.LoadLibrary for loading
Build system / Check kernel codestyle (pull_request) Successful in 1m27s
Details
Build system / Build (pull_request) Successful in 11m28s
Details
7d4b241afc 
Signed-off-by: hrigar <h4gar02@protonmail.com>
Doczom requested changes 2026-03-18 19:10:43 +00:00
Dismissed
programs/develop/libraries/dll/dll.inc Outdated
@@ -122,0 +99,4 @@
; if first function in export table begins with 'lib_', call it as DLL initialization
; return eax = pointer to export table, or 0 on failure
proc dll.LoadLibrary, lib_path:dword
mov esi, [lib_path]
Doczom commented 2026-03-18 19:10:33 +00:00
Owner
Copy Link
Copy Source

Error in the implementation of the calling convention for this function. There is no saving of ESI, EDI, EBX registers

Error in the implementation of the calling convention for this function. There is no saving of ESI, EDI, EBX registers
👍 1
hrigar commented 2026-03-18 22:53:17 +00:00
Author
Contributor
Copy Link
Copy Source

Fixed, preserving the registers now.

Fixed, preserving the registers now.
hrigar marked this conversation as resolved
dunkaist requested changes 2026-03-18 20:07:37 +00:00
programs/develop/libraries/dll/dll.asm Outdated
@@ -173,2 +173,2 @@
dll.GetProcAddress, 'dll_sym'
dll.GetProcAddress, 'dll_sym', \
dll.LoadLibrary, 'dll_LoadLibrary'
dunkaist commented 2026-03-18 20:06:42 +00:00
Owner
Copy Link
Copy Source

It is better to follow the existing name style: dll_load, dll_link, dll_sym. Hence, not dll_LoadLibrary but somethink like dll_loadlib, or dll_load_lib, dll_load_library

It is better to follow the existing name style: dll_load, dll_link, dll_sym. Hence, not dll_LoadLibrary but somethink like dll_loadlib, or dll_load_lib, dll_load_library
hrigar commented 2026-03-18 22:47:45 +00:00
Author
Contributor
Copy Link
Copy Source

Yes, renamed export to dll_loadlib

Yes, renamed export to `dll_loadlib`
hrigar marked this conversation as resolved
hrigar added 1 commit 2026-03-18 22:45:04 +00:00
dll: save non-volatile registers in dll.LoadLibrary, rename export to dll_loadlib
Build system / Check kernel codestyle (pull_request) Successful in 1m26s
Details
Build system / Build (pull_request) Successful in 10m41s
Details
319ed5606c 
Signed-off-by: hrigar <h4gar02@protonmail.com>
Doczom approved these changes 2026-03-21 17:32:26 +00:00
Dismissed
Doczom requested review from dunkaist 2026-03-21 17:32:39 +00:00
dunkaist requested changes 2026-03-23 23:31:36 +00:00
programs/dll.inc Outdated
@@ -90,0 +90,4 @@
or eax, eax
jz .fail
push eax
dunkaist commented 2026-03-23 23:26:03 +00:00
Owner
Copy Link
Copy Source

Is this push (and the corresponding pop) needed?

Is this push (and the corresponding pop) needed?
hrigar commented 2026-03-25 15:35:03 +00:00
Author
Contributor
Copy Link
Copy Source

Isn't it a calling convention for a caller to preserve eax, even though dll.Init currently doesn't modify eax?

Isn't it a calling convention for a caller to preserve eax, even though dll.Init currently doesn't modify eax?
dunkaist commented 2026-04-01 08:48:54 +00:00
Owner
Copy Link
Copy Source

dll.Init is an internal function that preserves all the registers itself. At the moment, these push/pop eax are redundant. In the future, dll.Init might return some value in eax, in which case push/pop eax will have to be removed anyway.

dll.Init is an internal function that preserves all the registers itself. At the moment, these push/pop eax are redundant. In the future, dll.Init might return some value in eax, in which case push/pop eax will have to be removed anyway.
👍 1
hrigar marked this conversation as resolved
programs/dll.inc Outdated
@@ -90,0 +100,4 @@
pop edi esi ebx
ret
.fail:
xor eax, eax
dunkaist commented 2026-03-23 23:30:22 +00:00
Owner
Copy Link
Copy Source

Is this xor needed?

Is this xor needed?
hrigar commented 2026-03-25 15:25:24 +00:00
Author
Contributor
Copy Link
Copy Source

No, its redundant. will remove this.

No, its redundant. will remove this.
hrigar marked this conversation as resolved
hrigar added 1 commit 2026-03-25 15:50:57 +00:00
dll.LoadLibrary: remove redundant xor eax, eax in fail path
Build system / Check kernel codestyle (pull_request) Successful in 1m47s
Details
Build system / Build (pull_request) Successful in 11m19s
Details
3c2dd3ab05 
Signed-off-by: hrigar <h4gar02@protonmail.com>
dunkaist requested changes 2026-04-01 08:52:05 +00:00
programs/develop/libraries/dll/dll.inc Outdated
@@ -64,12 +42,10 @@ proc dll.Load, import_table:dword
ret
.fail_load:
add esp, 4
dunkaist commented 2026-04-01 08:52:00 +00:00
Owner
Copy Link
Copy Source

Maybe this line and the 'ret' below can be removed.

Maybe this line and the 'ret' below can be removed.
👍 1
hrigar marked this conversation as resolved
programs/develop/libraries/dll/dll.inc Outdated
@@ -122,0 +126,4 @@
.done:
pop eax
pop edi esi ebx
ret
dunkaist commented 2026-04-01 08:50:40 +00:00
Owner
Copy Link
Copy Source

I believe this 'ret' and the above line can be safely removed.

I believe this 'ret' and the above line can be safely removed.
hrigar marked this conversation as resolved
hrigar added 1 commit 2026-04-03 14:23:06 +00:00
dll: remove redundant push/pop and merge exit paths
Build system / Check kernel codestyle (pull_request) Successful in 23s
Details
Build system / Build (pull_request) Successful in 9m52s
Details
5db327d4d8 
Signed-off-by: hrigar <h4gar02@protonmail.com>
Doczom requested changes 2026-04-11 16:46:19 +00:00
Dismissed
programs/dll.inc Outdated
@@ -31,2 +16,4 @@
pop edx
test eax, eax
jz .fail
stdcall dll.Link, eax, edx
Doczom commented 2026-04-11 16:45:56 +00:00
Owner
Copy Link
Copy Source

Please add a check for the success of the function, similar to the one in the dll.inc file for the library

Please add a check for the success of the function, similar to the one in the dll.inc file for the library
hrigar commented 2026-04-11 17:52:13 +00:00
Author
Contributor
Copy Link
Copy Source

added

added
hrigar marked this conversation as resolved
hrigar added 1 commit 2026-04-11 17:49:00 +00:00
dll.Load: add return value check after dll.Link
Build system / Build (pull_request) Failing after 1m20s
Details
Build system / Check kernel codestyle (pull_request) Successful in 1m43s
Details
dd0741701c 
Signed-off-by: hrigar <h4gar02@protonmail.com>
Doczom commented 2026-04-11 19:41:43 +00:00
Owner
Copy Link
Copy Source

the patch adds a check with a transition to a non-existent label

the patch adds a check with a transition to a non-existent label
hrigar added 1 commit 2026-04-13 13:59:39 +00:00
dll.Load: fix jump to non-existent label, reuse .fail
Build system / Check kernel codestyle (pull_request) Successful in 1m32s
Details
Build system / Build (pull_request) Successful in 11m48s
Details
8b33d9c403 
Signed-off-by: hrigar <h4gar02@protonmail.com>
Doczom approved these changes 2026-04-14 04:53:37 +00:00
Dismissed
Doczom requested review from dunkaist 2026-04-14 04:53:43 +00:00
Burer requested changes 2026-04-19 10:07:28 +00:00
Dismissed
Burer left a comment
Owner
Copy Link
Copy Source

I can see a crucial problem in current implementation:

  • Success path is treated as failure in dll.Load
    In programs/dll.inc (proc dll.Load, right after stdcall dll.Link), the new test eax, eax + jnz .fail logic is inverted.
    In this implementation, dll.Link returns non-zero on success and 0 on unresolved-symbol failure, so this check fails valid loads.
    Thus, you also need to change dll.Link and sync it's behaviour with library.
I can see a crucial problem in current implementation: - [x] ~Success path is treated as failure in `dll.Load` In `programs/dll.inc` (`proc dll.Load`, right after `stdcall dll.Link`), the new `test eax, eax` + `jnz .fail` logic is inverted. In this implementation, `dll.Link` returns non-zero on success and `0` on unresolved-symbol failure, so this check fails valid loads. Thus, you also need to change `dll.Link` and sync it's behaviour with library.~
Burer added 1 commit 2026-05-04 05:40:36 +00:00
programs/dll.inc: fix inverted Link result check in dll.Load
Build system / Check kernel codestyle (pull_request) Successful in 1m26s
Details
Build system / Build (pull_request) Successful in 10m57s
Details
eb022fef9e 
The inline dll.Link in this file returns the export-table pointer
(non-zero) on success and 0 if any import is unresolved - opposite
contract from the library-side dll.Link. The jnz .fail check after
dll.Link inverted that contract, so every successfully linked
library was reported as a failure, breaking all consumers of
programs/dll.inc.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Burer force-pushed feature/dll-LoadLibrary from bdd9489279 to eb022fef9e 2026-05-04 05:40:36 +00:00 Compare
Doczom approved these changes 2026-05-04 13:57:07 +00:00
Burer approved these changes 2026-05-04 19:02:49 +00:00
Burer merged commit e7698cbfb6 into main 2026-05-04 19:03:52 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
dunkaist
Doczom
Burer
Labels
Clear labels
C
Category/Applications
Category/Drivers
Category/General
Category/Kernel
Category/Libraries
Eolite
FASM
FS
GSoC
This issue in GSoC program
 HardwareTested
HLL
Influence/Settings
Influence/Text/TYPO
IRCC
Kernel
Kind
Breaking
Breaking change that won't be backward compatible
Kind
Bug
Something is not working
Kind
Build
Kind
Documentation
Documentation changes
Kind
Enhancement
Improve existing functionality
Kind
Feature
New functionality
Kind
Security
This is security issue
Kind
Testing
Issue or pull request related to testing
Pay for the code
Paid task
PR
Conflicts
PR conflicts with main
PR
Dependent
This PR is dependent on another PR
Priority
Critical
The priority is critical
Priority
High
The priority is high
Priority
Low
The priority is low
Priority
Medium
The priority is medium
PR
Ready to merge
Pull request is ready for merge
PR
Request changes
Changes requested in pull request
PR
Review required
Reviewed
Confirmed
Issue has been confirmed
Reviewed
Duplicate
This issue or pull request already exists
Reviewed
Invalid
Invalid issue
Reviewed
Won't Fix
This issue won't be fixed
Status
Abandoned
Somebody has started to work on this but abandoned work
Status
Blocked
Something is blocking this issue or pull request
Status
Need More Info
Feedback is required to reproduce issue or to continue work
No Label Category/Libraries FASM
Kind
Feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
ace-dent (Andrew) Burer Doczom (Mikhail Frolov) dunkaist (Ivan B) Egor00f (Егор) hidnplayr IgorA Leency (Kiril Lipatov) mxlgv (Max Logaev) ramenu rgimad sdongles (Serhii Sakhno) Sweetbread (Gleb Zaharov)
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: KolibriOS/kolibrios#370
Delete Branch "hrigar/kolibrios:feature/dll-LoadLibrary"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?