WTF Bites
-
@pie_flavor said in WTF Bites:
Except the way you hold off updates ad infinitum is by never turning off your computer. Or even just taking advantage of hybrid shutdown.
True.
There is no way to force updates on people without some inconvenience.
Sure, but there's "inconvenience" and there's
inconvenience
-
@Benjamin-Hall said in WTF Bites:
Serious question (yeah, I know that's
)--how does the OS know what programs/services are using what libraries? That is, how does it know which need to be restarted and which don't?There's probably a registration method somewhere, but that seems fragile.
If it's about libraries currently being used, that's easy: just look at what's mapped in the address space.
cat /proc/$PID/mapson Linux. As for libraries an executable might want to use, that's unknowable because you may as well take any user input and pass that todlopen()or something.
-
@TimeBandit said in WTF Bites:
Yeah, every programs and services uses EVERY library in the system, so if you update one library, you have to restart everything.
Does the OS even track which programs use which libraries? How about libraries that can be loaded/unloaded on demand? Can the OS predict that program A is 16 seconds away from opening library B and somehow know it needs to reboot it to account for an updated library B?
We're talking about computers. They're machines, not magic wizards.
Anybody? Yeah, I imagine that somebody with the resources of Microsoft could do better if they prioritized that. We're talking about a product that has lasted multiple decades, with several major redesigns along the way. Granted, Windows Update is a bit newer, but it has been around for a while (and the complaints are a bit newer again, but have been around for at least 3 or 4 major iterations).
They could probably do better.
So do that incrementally and in the background?
What a great user experience. "Oh you wanted this computer to serve a website? WELL IT'S NOT NOW! I KILLED THE WEB SERVER! SILENTLY AND IN THE BACKGROUND SO YOU DON'T EVEN KNOW! HAHA FUCK YOU USER!"
Nothing says that all of them have to be restarted at once.
Right; but you think just randomly restarting apps is a good idea as an alternative? Because that seems WAY worse to me.
For example, I don't care if the Visual Studio IDE restarts itself when I've locked my screen to get a cup of coffee or overnight or whatever, assuming it's back in the same state I left it when I'm back.
Windows is an OS, not a magical wizard. It has no way of predicting when you're going to come back to your computer.
And frankly the idiots in charge of Visual Studio right now can barely make a functional IDE, you're expecting way too much of them.
I mean, my fucking Android phone seems to be able to pull that off.
My Android phone reboots when it has updates.
Also it turns out when you build an OS from scratch in like 2009 you can do more modern stuff than you could do if you have to be compatible with every application written between 1995 and 2018. Shocking revelation.
Yet, in practice, that doesn't seem to be much of a problem.
Buggy is buggy. There's a lot of problems that Windows solves in an systematic way that Linux just shrugs and says "guess you just hope it won't happen!" That's because Windows had this thing called "designers" working on it, it's not just glommed together by hundreds of incompetent idiots.
@Benjamin-Hall said in WTF Bites:
Serious question (yeah, I know that's )--how does the OS know what programs/services are using what libraries?
It might be able to know which the programs are using currently. It has no way of knowing which the programs are about to use, which is really the problem.
The system already knows which libraries have been loaded by what processes.
Libraries can be loaded or unloaded at any time.
Your magical mystical solution needs to account for features the OS already has otherwise it's pretty fucking useless, yes?
-
@Benjamin-Hall said in WTF Bites:
@TimeBandit said in WTF Bites:
@blakeyrat said in WTF Bites:
That still requires you to reboot all the apps and services and is functionally identical to a reboot.
Yeah, every programs and services uses EVERY library in the system, so if you update one library, you have to restart everything.
Serious question (yeah, I know that's
)--how does the OS know what programs/services are using what libraries? That is, how does it know which need to be restarted and which don't?There's probably a registration method somewhere, but that seems fragile.
-
@anotherusername You people are computer programmers, right? You do realize that shared libraries can be loaded or unloaded at any time, right? You do understand that computers can't magically predict the future, right?
"HELLO I R DAILYWTF POSTAR. I KNOW ABSOLTELY NOTHNG ABOUT OSES. HERE'S MY SOLUTIN FOR OS PROBLMS!!! I R GENIUS MAN!!!!!! SOLVING ALL PROBLIMS!"
-
@blakeyrat said in WTF Bites:
Does the OS even track which programs use which libraries? How about libraries that can be loaded/unloaded on demand?
Yes.
Can the OS predict that program A is 16 seconds away from opening library B and somehow know it needs to reboot it to account for an updated library B?
Of course not, but it can suspend program A if it tries to open library B while library B is updating. And if updating library B before program A starts using it will crash program A, then either program A or library B is broken.
-
@blakeyrat said in WTF Bites:
You people are computer programmers, right? You do realize that shared libraries can be loaded or unloaded at any time, right?
Yes. But so what if they do? It should look like the same library if it unloads the old one and then reloads the new one, shouldn't it? If not, why would it be better to close the program in between having the library open?
-
@boomzilla said in WTF Bites:
Yes. But so what if they do? It should look like the same library if it unloads the old one and then reloads the new one, shouldn't it? If not, why would it be better to close the program in between having the library open?
What if I grab a data structure from Library B, storing it in my own memory. Then quit Library B. Then reload it an hour later and feed it the same data structure. But Library B changed, so the data structure's totally different, and now it all comes crashing down.
Now everybody's going to wave their arms in the air like a muppet and scream "this is a contrived example!" and maybe it's rare in day-to-day usage, but a software system is either correct or it's not.
-
@blakeyrat said in WTF Bites:
@boomzilla said in WTF Bites:
Yes. But so what if they do? It should look like the same library if it unloads the old one and then reloads the new one, shouldn't it? If not, why would it be better to close the program in between having the library open?
What if I grab a data structure from Library B, storing it in my own memory. Then quit Library B. Then reload it an hour later and feed it the same data structure. But Library B changed, so the data structure's totally different, and now it all comes crashing down.
Now everybody's going to wave their arms in the air like a muppet and scream "this is a contrived example!" and maybe it's rare in day-to-day usage, but a software system is either correct or it's not.
Yes. Someone is definitely doing weird and incorrect things there. Probably both the library and its consumer.
-
@blakeyrat said in WTF Bites:
Does the OS even track which programs use which libraries? How about libraries that can be loaded/unloaded on demand? Can the OS predict that program A is 16 seconds away from opening library B and somehow know it needs to reboot it to account for an updated library B?
Yes, there's a way for the OS¹ to know that program X requires library Y to work correctly: it's called a package manager. If a program declares a dependency on a library, the package manager will refuse to uninstall that library or replace it with an incompatible (as per API versioning) version. If a program does not declare that dependency and just relies on being able to open it anyway, well, bummer. Next time program better.
¹ i.e. "a sane OS"
-
@blakeyrat said in WTF Bites:
What if I grab a data structure from Library B, storing it in my own memory. Then quit Library B. Then reload it an hour later and feed it the same data structure. But Library B changed, so the data structure's totally different, and now it all comes crashing down.
You know what an API is, right?
-
@anotherusername said in WTF Bites:
And if updating library B before program A starts using it will crash program A, then either program A or library B is broken.
Or maybe there's library C that comes from the same software package as library B and they use some undocumented internal structures to communicate with each other, and program A loads library C and retrieves some object and then loads library B and passes that object to it and if the update included an ABI-incompatible change in the undocumented internal structures then KABOOM.
-
Yes, there's a way for the OS¹ to know that program X requires library Y to work correctly: it's called a package manager. If a program declares a dependency on a library, the package manager will refuse to uninstall that library or replace it with an incompatible (as per API versioning) version. If a program does not declare that dependency and just relies on being able to open it anyway, well, bummer. Next time program better.
¹ i.e. "a sane OS"So if I'm Paint.NET and I have a million plug-ins and all the plug-ins are implemented as DLLs (a perfectly reasonable way to implement software plug-ins), I need to somehow proactively list every plug-in a user could POSSIBLY have installed in this package manager? Updated in real-time?
That's... that's your solution?
-
@blakeyrat said in WTF Bites:
What if I grab a data structure from Library B, storing it in my own memory. Then quit Library B. Then reload it an hour later and feed it the same data structure. But Library B changed, so the data structure's totally different, and now it all comes crashing down.
You know what an API is, right?
You know what an ABI is, right?
-
You know what an API is, right?
Yup!
Are you trying to make some kind of point here, or just farting out words?
-
@blakeyrat said in WTF Bites:
What a great user experience. "Oh you wanted this computer to serve a website? WELL IT'S NOT NOW! I KILLED THE WEB SERVER! SILENTLY AND IN THE BACKGROUND SO YOU DON'T EVEN KNOW! HAHA FUCK YOU USER!"
You're missing the part about restarting it.
Look, we're getting fucking machine learning to decide when to reboot the computer so that it's less annoying. If nothing else, the same shit could be applied to decide when to restart your fucking web server so that it doesn't interfere with your work. At least not more than rebooting your machine at the same point in time would.
Right now, it's apparently OK hold off applying updates for a few hours. So, it's probably OK to hold off restarting the offending processes for a few hours too.
Does the OS even track which programs use which libraries? How about libraries that can be loaded/unloaded on demand? Can the OS predict that program A is 16 seconds away from opening library B and somehow know it needs to reboot it to account for an updated library B?
We're talking about computers. They're machines, not magic wizards.
No, but the OS could detect that library B is newer than program A when it does so and try to deal with it then.
And since you're going to ask for a solution to prove that magic isn't required, I'll propose the following: let it load the old version in that case, and add it to the list of processes that need to be restarted eventually. Again, a few hours aren't going to hurt. (The update process will have to hold on to the old versions for a while, but that doesn't seem an insurmountable problem either.)
And all of this shit that I'm "suggesting" is shit that I pull out-of-my-ass on demand (yours specifically). I'm sure there are problems and non-trivial issues, but I'm sure a team of engineers and developers spending more than 30 seconds thinking about it be able to come up with solutions if they really wanted...
Also it turns out when you build an OS from scratch in like 2009 you can do more modern stuff than you could do if you have to be compatible with every application written between 1995 and 2018. Shocking revelation.
Well, if they had attacked this problem in 2009, they'd maybe have something by now too.
-
@blakeyrat said in WTF Bites:
Yes, there's a way for the OS¹ to know that program X requires library Y to work correctly: it's called a package manager. If a program declares a dependency on a library, the package manager will refuse to uninstall that library or replace it with an incompatible (as per API versioning) version. If a program does not declare that dependency and just relies on being able to open it anyway, well, bummer. Next time program better.
¹ i.e. "a sane OS"So if I'm Paint.NET and I have a million plug-ins and all the plug-ins are implemented as DLLs (a perfectly reasonable way to implement software plug-ins), I need to somehow proactively list every plug-in a user could POSSIBLY have installed in this package manager? Updated in real-time?
Which part of "just relies on being able to open it anyway" didn't you understand?
If Paint.NET relies on being able to open all plugins without checking for errors, it's braindead. A plugin update that replaces a plugin with a version that's incompatible with your version of Paint is of course equally braindead, but first of all the error checking is Paint's job.You know what an API is, right?
You know what an ABI is, right?
Yes. Is that something you change without changing your library versions?
-
Or maybe there's library C that comes from the same software package as library B and they use some undocumented internal structures to communicate with each other, and program A loads library C and retrieves some object and then loads library B and passes that object to it and if the update included an ABI-incompatible change in the undocumented internal structures then KABOOM.
Yes, that's the usual sequence of events when software is shit.
-
@blakeyrat said in WTF Bites:
What if I grab a data structure from Library B, storing it in my own memory. Then quit Library B. Then reload it an hour later and feed it the same data structure. But Library B changed, so the data structure's totally different, and now it all comes crashing down.
What if you grab a data structure from Library B, saving it to disk. Then quit Library B and exit the program. Then when the user reopens that file, reload it a year later and feed it the same data structure. But Library B changed, so the data structure's totally different, and now it all comes crashing down.
Like @boomzilla said, that's
. Either the software, for storing something that wasn't meant to be used for persistent data storage, or the library, for breaking backward compatibility of something that was meant to be used for persistent data storage, or both. Probably both.
-
@blakeyrat said in WTF Bites:
Does the OS even track which programs use which libraries? How about libraries that can be loaded/unloaded on demand?
Do you know how an OS work?
The kernel knows what program loaded what library.
Can the OS predict that program A is 16 seconds away from opening library B and somehow know it needs to reboot it to account for an updated library B?
in 16 seconds, the new version of the library will get loaded. No reason to restart that program.
They could probably do better.
PROBABLY
What a great user experience. "Oh you wanted this computer to serve a website? WELL IT'S NOT NOW! I KILLED THE WEB SERVER! SILENTLY AND IN THE BACKGROUND SO YOU DON'T EVEN KNOW! HAHA FUCK YOU USER!"
Restarting Apache takes about 1/4 of a second. I often do it on live servers without any user noticing.
Your solution is way better: REBOOT THE WHOLE SERVER!!! That's a GREAT user experience
My Android phone reboots when it has updates.
Your phone reboots when it updates an app
Also it turns out when you build an OS from scratch in like 2009 you can do more modern stuff than you could do if you have to be compatible with every application written between 1995 and 2018. Shocking revelation.
Unix was designed in 1969
It might be able to know which the programs are using currently. It has no way of knowing which the programs are about to use, which is really the problem.
Why the fuck is it a problem?
-
You know what an API is, right?
You know what an ABI is, right?
Yes. Is that something you change without changing your library versions?
We're talking about updates. An update WILL change library version. And even if the public ABI stays the same, internal ABI might not.
-
Or maybe there's library C that comes from the same software package as library B and they use some undocumented internal structures to communicate with each other, and program A loads library C and retrieves some object and then loads library B and passes that object to it and if the update included an ABI-incompatible change in the undocumented internal structures then KABOOM.
Yes, that's the usual sequence of events when software is shit.
Are you saying there shall be no undocumented internal structures at all? How do you update anything ever in that case?
-
@blakeyrat said in WTF Bites:
Yes, there's a way for the OS¹ to know that program X requires library Y to work correctly: it's called a package manager. If a program declares a dependency on a library, the package manager will refuse to uninstall that library or replace it with an incompatible (as per API versioning) version. If a program does not declare that dependency and just relies on being able to open it anyway, well, bummer. Next time program better.
¹ i.e. "a sane OS"So if I'm Paint.NET and I have a million plug-ins and all the plug-ins are implemented as DLLs (a perfectly reasonable way to implement software plug-ins), I need to somehow proactively list every plug-in a user could POSSIBLY have installed in this package manager? Updated in real-time?
That's... that's your solution?
A smart solution would be to get rid of any residual plug-in stuff when you unload the plug-in. Why would you keep stuff like that around in the first place?
-
You know what an ABI is, right?
Yes. Is that something you change without changing your library versions?
We're talking about updates. An update WILL change library version.
Yeah, I should have said "in an API versioning sense", i.e. incompatibly. Which is something an update should not do. If either API or ABI changes, it requires at least recompilation if not source-level changes of all applications, so updated versions like this are usually installable alongside each other. The old version sticks around (and is separately maintained) so there's no problem.
And even if the public ABI stays the same, internal ABI might not.
If software does "internal ABI" fuckery between independently updatable parts, it's simply inviting disaster for no reason.
-
Or maybe there's library C that comes from the same software package as library B and they use some undocumented internal structures to communicate with each other, and program A loads library C and retrieves some object and then loads library B and passes that object to it and if the update included an ABI-incompatible change in the undocumented internal structures then KABOOM.
Yes, that's the usual sequence of events when software is shit.
Are you saying there shall be no undocumented internal structures at all? How do you update anything ever in that case?
Um, I think he's saying that if you use undocumented internal structures from code that you don't control you're
. Are you actually defending that practice?
-
And even if the public ABI stays the same, internal ABI might not.
If software does "internal ABI" fuckery between independently updatable parts, it's simply inviting disaster for no reason.
They're only independently update-able when doing this live-replacing fuckery @cvi is talking about. In a sane world, update is delayed until all interested parties are shut down.
-
If software does "internal ABI" fuckery between independently updatable parts, it's simply inviting disaster for no reason.
If they change the internals of something that's supposed to be an opaque pointer then I don't think that's inviting disaster except upon the people who deserve it for spelunking in there when they should know better.
And hanging onto stuff like that between unloading and then reloading a plugin makes no sense to me either.
-
@TimeBandit said in WTF Bites:
@cvi said in WTF Bites:
My Android phone reboots when it has updates.@cvi didn't say that. :-/
-
Or maybe there's library C that comes from the same software package as library B and they use some undocumented internal structures to communicate with each other, and program A loads library C and retrieves some object and then loads library B and passes that object to it and if the update included an ABI-incompatible change in the undocumented internal structures then KABOOM.
Yes, that's the usual sequence of events when software is shit.
Are you saying there shall be no undocumented internal structures at all? How do you update anything ever in that case?
Internal structures. Internal. To the library. If something external fucks around with internal structures, there's trouble. If you pass a structure to the outside via a documented API, it's no longer internal.
-
Which part of "just relies on being able to open it anyway" didn't you understand?
The everything.
If Paint.NET relies on being able to open all plugins without checking for errors, it's braindead. A plugin update that replaces a plugin with a version that's incompatible with your version of Paint is of course equally braindead, but first of all the error checking is Paint's job.
It uses that .NET technology I can never remember the name of (TEM? TLM? It's a three letter acronym) that lets .NET assemblies talk to each other without either side needing full knowledge of what the other side provides.
@TimeBandit said in WTF Bites:
Unix was designed in 1969
And it's really shitty isn't it.
@TimeBandit said in WTF Bites:
Why the fuck is it a problem?
I guess I'm just a stupid dumb idiot moron. Whatever, sick of this discussion.
-
-
Or maybe there's library C that comes from the same software package as library B and they use some undocumented internal structures to communicate with each other, and program A loads library C and retrieves some object and then loads library B and passes that object to it and if the update included an ABI-incompatible change in the undocumented internal structures then KABOOM.
Yes, that's the usual sequence of events when software is shit.
Are you saying there shall be no undocumented internal structures at all? How do you update anything ever in that case?
Internal structures. Internal. To the library.Because it's impossible for a library to consist of multiple DLL modules.
Another scenario when shit can blow up: when two independent programs use a single library to communicate with each other. If they don't use the exact same version of the file, things can blow up very easily even if all the changes are to this single DLL's internals. And without locking the DLL file when in use, you have no guarantee they're the exact same version.
-
In a sane world, update is delayed until all interested parties are shut down.
Well, that "sane" world is where we're at now: Windows telling me that it's going to reboot my machine so it can apply its updates.
-
If you pass a structure to the outside via a documented API, it's no longer internal.
What if you only pass a pointer and never define the contents of the object it points to? Is such thing disallowed in Well Done Software™?
-
@blakeyrat said in WTF Bites:
@TimeBandit said in WTF Bites:
Unix was designed in 1969
And it's really shitty isn't it.
No, it can even update a library without rebooting my computer. Imagine that
-
In a sane world, update is delayed until all interested parties are shut down.
Well, that "sane" world is where we're at now: Windows telling me that it's going to reboot my machine so it can apply its updates.
More sane than Windows not telling you that it's going to apply its updates.
-
@TimeBandit said in WTF Bites:
@blakeyrat said in WTF Bites:
@TimeBandit said in WTF Bites:
Unix was designed in 1969
And it's really shitty isn't it.
No, it can even update a library without rebooting my computer. Imagine that
And then you have problems with random programs randomly crashing or being unable to communicate with random parts of the system (in particular, with display manager) until you do full reboot. BTDT.
-
-
@blakeyrat said in WTF Bites:
@TimeBandit said in WTF Bites:
Why the fuck is it a problem?
I guess I'm just a stupid dumb idiot moron.
Common ground at last?
-
More sane than Windows not telling you that it's going to apply its updates.
I'm on the fence regarding that - a few years ago I would have agreed with you, now I'm not so sure anymore.
Essentially:
-
Android and other app-store based infrastructures get away with not telling. I struggled against that for a while, but ended up giving up. Now my apps/user-land is automatically up-to-date, and I'm surprisingly OK with that for the most part.
-
Windows is going to insist on applying the updates anyway eventually, so it might just go ahead and do it without bugging me about it and (perhaps more importantly) without me noticing or being interrupted by the process.
(Mind you, I'm talking about Windows on an interactive work-station, not for a server. I'm not using Windows on the latter, but I can understand if people want more control there.)
-
-
And then you have problems with random programs randomly crashing or being unable to communicate with random parts of the system (in particular, with display manager)
Never happened to me in 19 years
-
@TimeBandit said in WTF Bites:
And then you have problems with random programs randomly crashing or being unable to communicate with random parts of the system (in particular, with display manager)
Never happened to me in 19 years
And Windows has never rebooted on me without warning
-
Or maybe there's library C that comes from the same software package as library B and they use some undocumented internal structures to communicate with each other, and program A loads library C and retrieves some object and then loads library B and passes that object to it and if the update included an ABI-incompatible change in the undocumented internal structures then KABOOM.
Yes, that's the usual sequence of events when software is shit.
Are you saying there shall be no undocumented internal structures at all? How do you update anything ever in that case?
Internal structures. Internal. To the library.Because it's impossible for a library to consist of multiple DLL modules.
Another scenario when shit can blow up: when two independent programs use a single library to communicate with each other. If they don't use the exact same version of the file, things can blow up very easily even if all the changes are to this single DLL's internals. And without locking the DLL file when in use, you have no guarantee they're the exact same version.
Hmm....would you get two versions of the library in the process or would it just reuse the already linked version in that case?
Scenario:
- Main process opens
liba, getsliba.1 libais updated (a la Linux, so the file on disk is nowliba.2but the main process still has the old version in memory)- Main process opens
libb libbloadsliba(what does it get?)- Main process and
libbtry to uselibato communicate
It's been a while since I've fooled around at this level and I've never played with exactly these circumstances but it seems like if
libbgotliba.2then the main process couldn't uselibato talk tolibbsince they'd be talking to differentlibas.
- Main process opens
-
Another scenario when shit can blow up: when two independent programs use a single library to communicate with each other. If they don't use the exact same version of the file, things can blow up very easily even if all the changes are to this single DLL's internals. And without locking the DLL file when in use, you have no guarantee they're the exact same version.
Both programs would be forced to close so that the DLL file could be updated. There's no way they should end up using different versions of it, if and when they're restarted.
-
@blakeyrat said in WTF Bites:
And frankly the idiots in charge of Visual Studio right now can barely make a functional IDE, you're expecting way too much of them.
And yet you still refuse to try a JetBrains product simply because of what it's written in.
-
@blakeyrat said in WTF Bites:
You know what an API is, right?
Yup!
Are you trying to make some kind of point here, or just farting out words?
-
@blakeyrat said in WTF Bites:
If Paint.NET relies on being able to open all plugins without checking for errors, it's braindead. A plugin update that replaces a plugin with a version that's incompatible with your version of Paint is of course equally braindead, but first of all the error checking is Paint's job.
It uses that .NET technology I can never remember the name of (TEM? TLM? It's a three letter acronym) that lets .NET assemblies talk to each other without either side needing full knowledge of what the other side provides.
But then it crashes if the thing it things needs to be provided isn't (any more)?
Internal structures. Internal. To the library.Because it's impossible for a library to consist of multiple DLL modules.
If they do, they'd better make sure they get the right version before assuming stuff about internals
Another scenario when shit can blow up: when two independent programs use a single library to communicate with each other. If they don't use the exact same version of the file, things can blow up very easily even if all the changes are to this single DLL's internals. And without locking the DLL file when in use, you have no guarantee they're the exact same version.
I don't even understand how that would work. When both partners have the library open, it isn't going to be unloaded even if the file on disk is updated. If one side closes communication by closing the library, it can't expect the other side to be there when it reopens the library. Might as well be that the other side is busy with something.
If you pass a structure to the outside via a documented API, it's no longer internal.
What if you only pass a pointer and never define the contents of the object it points to? Is such thing disallowed in Well Done Software™?
It's not explicitly defined for Unix's
dlopen(I guess nobody thought anyone might assume you could continue using a library's resources after closing it) but Windows documentation reads very much like "that would be a very bad idea":Before unloading a library module, the system enables the module to detach from the process by calling the module's DllMain function, if it has one, with the DLL_PROCESS_DETACH value. Doing so gives the library module an opportunity to clean up resources allocated on behalf of the current process. After the entry-point function returns, the library module is removed from the address space of the current process.
If I know the DLL is allowed to "clean up" shit it gave me, I wouldn't assume I'm allowed to hang on to any pointers.
-
If I know the DLL is allowed to "clean up" shit it gave me, I wouldn't assume I'm allowed to hang on to any pointers.
I could imagine a situation where I gave the plugin a pointer to some memory that I controlled for it to write some stuff to. And then using that back and forth. Of course, I'd still be worried about the stuff it was putting in there.
I still can't get my head around the idea of using library resources after closing the library and then reopening the library and expecting everything to work, though I suppose I can certainly imagine people not understanding all the Bad Ideas involved in that.
-
@boomzilla said in WTF Bites:
I still can't get my head around the idea of using library resources after closing the library and then reopening the library and expecting everything to work, though I suppose I can certainly imagine people not understanding all the Bad Ideas involved in that.
Well I might use the library to generate a PNG file, then unload it, then load it again when an hour later I need to display that PNG file.
Now obviously that's stupid because PNG is a standard format.
But what if it's a custom proprietary format? It seems like a perfectly reasonable thing to do to me at least.
-
@blakeyrat said in WTF Bites:
@boomzilla said in WTF Bites:
I still can't get my head around the idea of using library resources after closing the library and then reopening the library and expecting everything to work, though I suppose I can certainly imagine people not understanding all the Bad Ideas involved in that.
Well I might use the library to generate a PNG file, then unload it, then load it again when an hour later I need to display that PNG file.
Now obviously that's stupid because PNG is a standard format.
But what if it's a custom proprietary format? It seems like a perfectly reasonable thing to do to me at least.
It still gives me the willies and a very strong smell. And I'm back to, "Why would you keep this proprietary data around when you've just unloaded the stuff that uses it?" If it's a file that you can save and load then it seems like this update thing shouldn't matter, because either it will break after an update and reloading an old file or it's smart enough to detect an older version and deal with that by converting it or just using the older format, like all the
Exstructures you get in Win32 and COM.And if you don't bother with the provided serialization stuff (still working on the assumption that it's some sort of file thing) then again you're risking that it has some pointers to long gone memory, maybe reused and you're corrupting all sorts of stuff. And that's a risk even if the library didn't update between when you closed it and then reopened it.
