The Official Status Thread
-
@Tsaukpaetra on Lunix:
extern "C" { fn foobar(); }
on Windows:
#[link(name="foobar.dll", kind="dylib")] extern "C" { fn foobar(); }
Which is not extremely conducive to plugin-oriented design, since the thing that provides the functions would be calling the DLL instead of the other way around.
-
@pie_flavor said in The Official Status Thread:
on Windows:
#[link(name="foobar.dll", kind="dylib")] extern "C" { fn foobar(); }
But, I thought in Rust it "just works"?
-
@Tsaukpaetra you can't get around that fun little bit of platform incompatibility. MSVC only, too. The reason it generally 'just works' is that nearly nothing is dynamically linked in Rust, but in the rare event that you do, you run into this problem.
-
@pie_flavor said in The Official Status Thread:
@Tsaukpaetra you can't get around that fun little bit of platform incompatibility. MSVC only, too. The reason it generally 'just works' is that nearly nothing is dynamically linked in Rust.
But I'm confused, since you said you were
@pie_flavor said in The Official Status Thread:
refer to undefined symbols
Which is incomprehensible to me.
Are you saying you're referring to functions you don't know exist?
I'm trying to figure out what it is you're trying to accomplish with this...
-
@Tsaukpaetra program A has plugin compatibility. so any DLLs in a particular folder, including DLL B, get loaded at runtime and a particular exported symbol is called. This is an inverse of how DLLs are supposed to work; the program provides the library functions to the DLL instead of the other way around. This is fine on non-Windows systems, because externally-defined functions can be referenced even if you don't specify the DLL name as long as the function exists at runtime. Windows however does not have an 'amorphous blob' model of functions, and requires that you say what DLL each function comes from. This means that this plugin compatibility model is impossible in Windows.
Unless of course you pass a struct to that particular exported symbol containing all your library function pointers. Which is the solution I'm currently running with.
-
@topspin said in The Official Status Thread:
normally I'd assume working with machine word sizes produces smaller code?
Very hard to say for sure. Overall code size is dependent on all sorts of things.
-
@pie_flavor said in The Official Status Thread:
Windows however does not have an 'amorphous blob' model of functions, and requires that you say what DLL each function comes from.
No. You can do true runtime lookup too. It's very much unsafe in a Rust sense (I hope! It literally cannot be safe as it can do arbitrary things without official semantic constraints) but the fundamental OS functions for doing this are all there and aren't more difficult to use than
dlopen
/dlsym
on POSIX.
-
@dkf You can, except you can't put it in a .h file. A client application would be entirely on its own there.
-
Status: Behold, our most devoted fans (until the special event ends) and the currently online population of the game!
(they're all kids.)
-
@Tsaukpaetra said in The Official Status Thread:
currently online
Status: Really need to implement idle kicking....
-
@pie_flavor said in The Official Status Thread:
@Tsaukpaetra program A has plugin compatibility. so any DLLs in a particular folder, including DLL B, get loaded at runtime and a particular exported symbol is called. This is an inverse of how DLLs are supposed to work; the program provides the library functions to the DLL instead of the other way around. This is fine on non-Windows systems, because externally-defined functions can be referenced even if you don't specify the DLL name as long as the function exists at runtime. Windows however does not have an 'amorphous blob' model of functions, and requires that you say what DLL each function comes from. This means that this plugin compatibility model is impossible in Windows.
Unless of course you pass a struct to that particular exported symbol containing all your library function pointers. Which is the solution I'm currently running with.Can't you link the .dll to the binary, i.e. the reverse dependency you normally have, then
LoadLibrary
the .dll? I'm almost sure that the dependencies of a .dll can include .exe's (they're all PE images in the end), but no idea if such a cyclical loading works.
-
@Tsaukpaetra said in The Official Status Thread:
Status: Behold, our most devoted fans (until the special event ends) and the currently online population of the game!
(they're all kids.)
Is there anything wrong with the usernames that I'm missing?
-
@topspin That there's three?
-
@kazitor I missed the part where that's the only players. Thanks.
-
@dcon said in The Official Status Thread:
Am I missing something? Looks like you never "print" the first character. And you read past the end of the message buffer.
No you're not missing anything, found that when I ran it, increment was in the wrong place, needed to be a post-increment on the
memcpy
.I don't see the read past the end of
message
though?Edit: Oh, I see. Duh. Well, it actually works fine with the display...so let's just ship it...
Edit2: Goddamnit,
sizeof
is not a runtime evaluation on this compiler. This is going to be a pain in the butt.
-
@topspin said in The Official Status Thread:
@pie_flavor said in The Official Status Thread:
@Tsaukpaetra program A has plugin compatibility. so any DLLs in a particular folder, including DLL B, get loaded at runtime and a particular exported symbol is called. This is an inverse of how DLLs are supposed to work; the program provides the library functions to the DLL instead of the other way around. This is fine on non-Windows systems, because externally-defined functions can be referenced even if you don't specify the DLL name as long as the function exists at runtime. Windows however does not have an 'amorphous blob' model of functions, and requires that you say what DLL each function comes from. This means that this plugin compatibility model is impossible in Windows.
Unless of course you pass a struct to that particular exported symbol containing all your library function pointers. Which is the solution I'm currently running with.Can't you link the .dll to the binary, i.e. the reverse dependency you normally have, then
LoadLibrary
the .dll? I'm almost sure that the dependencies of a .dll can include .exe's (they're all PE images in the end), but no idea if such a cyclical loading works.You can't link to an executable.
-
@pie_flavor said in The Official Status Thread:
You can, except you can't put it in a .h file.
Are we talking about a plugin exporting an API to its host application? Because that's deeply crazy. Exporting an implementation of an interface is possible since the plugin can call an implementation registration function, but you can't export an actual API without deep shenanigans (because calling an API you've not built the code to use is where you're into all the !!fun!! of soft binding).
Exporting an API from one plugin to another is possible, but quite remarkably tricky. Especially on Windows, where API bindings are usually done at compile time. (Also, you'd better be doing so in a DAG of dependencies; circular dependencies are where you go straight back into the land of crazy and/or fail.)
-
@topspin said in The Official Status Thread:
no idea if such a cyclical loading works
It usually doesn't, unless you make the binding weak somewhere. Weak bindings can be unsatisfied, so the DLL that uses them needs to be prepared for them being NULL until the dependency loop is actually fully loaded. This stuff is really difficult to get right, and fantastically easy to get wrong (with a very strange crash too) so sensible programmers try to avoid it.
-
Status: Learning to write makefiles. In other news, hooking up Cygwin to VSCode was surprisingly easy.
-
@pie_flavor said in The Official Status Thread:
@topspin said in The Official Status Thread:
@pie_flavor said in The Official Status Thread:
@Tsaukpaetra program A has plugin compatibility. so any DLLs in a particular folder, including DLL B, get loaded at runtime and a particular exported symbol is called. This is an inverse of how DLLs are supposed to work; the program provides the library functions to the DLL instead of the other way around. This is fine on non-Windows systems, because externally-defined functions can be referenced even if you don't specify the DLL name as long as the function exists at runtime. Windows however does not have an 'amorphous blob' model of functions, and requires that you say what DLL each function comes from. This means that this plugin compatibility model is impossible in Windows.
Unless of course you pass a struct to that particular exported symbol containing all your library function pointers. Which is the solution I'm currently running with.Can't you link the .dll to the binary, i.e. the reverse dependency you normally have, then
LoadLibrary
the .dll? I'm almost sure that the dependencies of a .dll can include .exe's (they're all PE images in the end), but no idea if such a cyclical loading works.You can't link to an executable.
I'm pretty sure (though not 100%) I've read somewhere you can. Even if not you can just put all of your stuff from your main exe into a dll and just have the exe wrap a single call into the dll.
-
@Gąska said in The Official Status Thread:
Learning to write makefiles.
I tried to google that quip about how when they figured out the
bugfeature that indentation needs to be TAB, they already "had 10 users", but I can't find it.
-
@Cursorkeys said in The Official Status Thread:
This is going to be a pain in the butt.
It was. Also, I should not be let near C again.
It's now an abomination, but it works and has intro/outro padding:
void DisplayScrollPaddedMessage(char* messageArray, char paddingChar) { unsigned char messageLen = 0; unsigned char padLenRequired; unsigned char x = 0; unsigned char y; //Get the message length while(*(messageArray + x++) != '\0') { messageLen++; } for (x = 0; x < (messageLen + 4); x++) //Four chars extra for outro padding { if (x < 4) { //Do the front padding padLenRequired = (4 - x); for (y = 0; y < padLenRequired; y++) { *(((char*)DisplayTextBuffer) + y) = paddingChar; } memcpy((((char*)DisplayTextBuffer) + padLenRequired), messageArray, x); } else if (((messageLen + 4) - x) < 4) { //Do the end padding padLenRequired = (4 - ((messageLen + 4) - x)); memcpy(DisplayTextBuffer, messageArray++, (4 - padLenRequired)); for (y = 0; y < padLenRequired; y++) { *(((char*)DisplayTextBuffer) + (3 - y)) = paddingChar; } } else { //Scrolling the middle of the message (if there is one) memcpy(DisplayTextBuffer, messageArray++, 4); } delay_250ms(1); } }
.
/
W
's are hard...
-
Status: The power is out.
-
Status: “It's not bricked. It's just running in SECURE mode.”
-
@PleegWat said in The Official Status Thread:
Status: The power is out.
Power is restored. Was about an hour total.
-
status: https://gluon-lang.org seems to have died while I was reading it. Oh well, I didn't like functional anyway. Now to choose between Rhai and Dyon for scripting...
-
@pie_flavor I wonder whether Gluon was made for manipulating strings…
-
@topspin said in The Official Status Thread:
@pie_flavor said in The Official Status Thread:
@topspin said in The Official Status Thread:
@pie_flavor said in The Official Status Thread:
@Tsaukpaetra program A has plugin compatibility. so any DLLs in a particular folder, including DLL B, get loaded at runtime and a particular exported symbol is called. This is an inverse of how DLLs are supposed to work; the program provides the library functions to the DLL instead of the other way around. This is fine on non-Windows systems, because externally-defined functions can be referenced even if you don't specify the DLL name as long as the function exists at runtime. Windows however does not have an 'amorphous blob' model of functions, and requires that you say what DLL each function comes from. This means that this plugin compatibility model is impossible in Windows.
Unless of course you pass a struct to that particular exported symbol containing all your library function pointers. Which is the solution I'm currently running with.Can't you link the .dll to the binary, i.e. the reverse dependency you normally have, then
LoadLibrary
the .dll? I'm almost sure that the dependencies of a .dll can include .exe's (they're all PE images in the end), but no idea if such a cyclical loading works.You can't link to an executable.
I'm pretty sure (though not 100%) I've read somewhere you can. Even if not you can just put all of your stuff from your main exe into a dll and just have the exe wrap a single call into the dll.
I seem to recall that EXE's and DLL's are the exact same format, and the only difference is EXE's have a
main
orWinMain
function. I know this is true for .NET. I once made a coworker cringe in horror by having a .NET application link some functions from another .NET EXE (it was a tiny EXE and pulling the two little functions out into their own DLL didn't seem to be worth the effort).
-
Status: Colleagues insist on calling JavaScript Java. They are having a very loud conversation about it currently
-
@mott555
Not quite. .NET binaries do not populate the PE export table. Instead, CLR builds its own by looking at the IL metadata upon loading the module. Unmanaged code cannot directlyGetProcAddress()
(of course, there are workarounds).
-
@Applied-Mediocrity said in The Official Status Thread:
of course, there are workarounds
I'm scared.
-
@kazitor said in The Official Status Thread:
Dammit, I was fooled into looking at an oblique projection.
Maybe I can grant artistic licence…
Though it doesn't look as bad when scaled down and put on a proper background.
I need to finish Spacechem. It gets tediously annoying later.
-
-
@JazzyJosh said in The Official Status Thread:
Me: Gets upvote notification
*Tsaukpaetra*
Me:
I had over 52 this morning and came.
-
@JazzyJosh You could make a program to solve spacechem levels!
-
@Cursorkeys said in The Official Status Thread:
@Cursorkeys said in The Official Status Thread:
Nice VFD! Where is it from?
-
@Zerosquare said in The Official Status Thread:
@Cursorkeys said in The Official Status Thread:
@Cursorkeys said in The Official Status Thread:
Nice VFD! Where is it from?
Just an LED I'm afraid, it's a custom one for this product. I'll have to blame my phone camera for the colour, it's apple-green in real life.
-
Status: The real reason IT people often get seen as psychic/wizards... so often, the troubleshooting process winds up being "look through what it's doing, eliminate what you know isn't the problem, and then ask 'hey what about this?'" At which point, what at first seemed non-obvious winds up being so obvious once you start looking in that area for the problem, and bamf Psychic Troubleshooting!
-
Status: My daughter called me at work to ask a hypothetical question: If a hypothetical friend had a hypothetical that was hypothetically too big to flush down a hypothetical toilet — not clogged, hypothetically, but too hypothetically big to go around the S-curve in the hypothetical plumbing — what hypothetical way could this hypothetical friend break the hypothetical into hypothetical pieces hypothetically small enough to hypothetically flush down the hypothetical toilet? Hypothetically speaking.
My daughter is 20-something, and I really don't want to know that much about her "hypothetical friend's" hypothetical s.
-
@HardwareGeek Sounds like good material for the old YouTube "Will It Blend?" series!
-
@HardwareGeek said in The Official Status Thread:
Status: My daughter called me at work to ask a hypothetical question: If a hypothetical friend had a hypothetical that was hypothetically too big to flush down a hypothetical toilet — not clogged, hypothetically, but too hypothetically big to go around the S-curve in the hypothetical plumbing — what hypothetical way could this hypothetical friend break the hypothetical into hypothetical pieces hypothetically small enough to hypothetically flush down the hypothetical toilet? Hypothetically speaking.
My daughter is 20-something, and I really don't want to know that much about her "hypothetical friend's" hypothetical s.
That sounds like it needs the solution from the best reddit thread of all time:
-
@Cursorkeys TIL. And I was originally going to make a joke about chopping it up with a metal spatula.
-
@JazzyJosh said in The Official Status Thread:
@kazitor said in The Official Status Thread:
Dammit, I was fooled into looking at an oblique projection.
Maybe I can grant artistic licence…
Though it doesn't look as bad when scaled down and put on a proper background.
I need to finish Spacechem. It gets tediously annoying later.
Oooh yeah. It happens quite suddenly too.
-
@HardwareGeek said in The Official Status Thread:
what hypothetical way could this hypothetical friend break the hypothetical into hypothetical pieces hypothetically small enough to hypothetically flush down the hypothetical toilet?
So long as you don't have open sores, it should be safe just to mash it manually.
Filed under: The lack of emoji in the select-to-quote made it better
-
@Tsaukpaetra said in The Official Status Thread:
open sores
Should be fine then, unless it's an IoT toilet.
-
@izzion said in The Official Status Thread:
Status: The real reason IT people often get seen as psychic/wizards... so often, the troubleshooting process winds up being "look through what it's doing, eliminate what you know isn't the problem, and then ask 'hey what about this?'" At which point, what at first seemed non-obvious winds up being so obvious once you start looking in that area for the problem, and bamf Psychic Troubleshooting!
Raymond Chen has a whole series of posts titled "Psychic Debugging".
-
Status: Tried the broken-as-ever search function to find one of my own recent posts. Instead I found a completely unrelated post from 2011 where I got blakeyranted at for
no reason at allunderstanding the OP without being psychic. And of course he promptly got called an idiot by @boomzilla.Status2: Oh dear, I'm up way to late again.
-
status: chagrin.
Yes, it's probably exactly like you think, and I'm sorry.
-
@Tsaukpaetra
This is why you shouldn't screw around with your computer.
-
@izzion said in The Official Status Thread:
@Tsaukpaetra
This is why you shouldn't screw around with your computer.It's not my computer.... Remember, this is the CT machine I mentioned on Saturday...