switch to room list switch to menu My folders
Go to page: First ... 9 10 11 12 [13] 14 15 16 17 ... Last
[#] Fri Aug 15 2008 15:18:58 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I generally compile statically to avoid having to include a DLL.

Well, try doing that with a Qt app. Technically, it might not be a good idea to statically link to the MSVC runtime while a Qt DLL also statically links to the same runtime. It's like you and your team and carrying unlicensed particle accelerators on your back, and aim them at a target, while crossing the ion streams. It would be bad.

You'd end up statically linking with Qt as well, which is just kind of bloated and slow during the linking process...

You can install the DLL in your app directory but according to MS licensing you must distribute the bundle directory in its entirety. So you end up with a subdirectory containing 3 DLL's and the manifest, when you might only need 1 or 2 of the 3.

[#] Fri Aug 15 2008 15:30:46 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Are you allocating and deallocating memory across the Qt DLL boundary? That is, for example, are you allocating memory within your app, and having Qt deallocate the memory you allocated?

If you are, yeah, you are opening yourself up to some interesting times.

Similiarly, if you're using similiar functions across the DLL boundary, you may get mixed results (e.g. string collation... I knew someone who had subtly different string collations across dll boundaries, leading to some amusingly confusing results).

But, normally, these kinds of things can be controlled.

And one of the ways you control this is by compiling the third party toolkit yourself, if you can. Then you know you're on the same page as the rest of your application.

Really, though, you're only trading one form of hell for another, I guess.
But, as respective hells go, I'll stick with the static-library hell over the dynamic library hell.

At least I can control the static-library hell. I can't control the dynamic library hell at all; some customer will install something that will absolutely fuck you up, and you won't even know why.

[#] Fri Aug 15 2008 15:37:30 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I actually tried and failed to build Qt statically. I already had a working DLL build, so I didn't bother trying to figure out the cause. There were some undefined symbols (in one of the Qt samples or utilities, if I remember correctly.)

Do DLL's have a different heap than the calling process? That sounds... phenomenally stupid.

I'd already known that you couldn't pass C/C++ runtime library data structures to a DLL that is linked with a different copy or different version of the runtime. For example, you can't pass a stdio FILE* to such, for obvious reasons. I wasn't aware that the problem extended to all memory allocations, even if there is only one copy of the runtime at play.

[#] Fri Aug 15 2008 15:42:55 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

The problem is more subtle.

The functions for allocating and deallocating memory differ slightly from debug/release versions of the C runtime. Further, they differ between dynamic and static versions of the C runtime. It isn't beyond imagination that they can differ between versions of the damned runtime.

As a consequence, if you mix-and-match allocation/deallocation across the DLL boundary, you risk using a routine that doesn't know how to deallocate the memory you allocated, but thinks that it does know how.

If this sounds phenomenally stupid, well... it is.

[#] Fri Aug 15 2008 15:46:21 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

but it sounds like you're describing a problem that only surfaces when you have more than one runtime library in scope. example: my application is linked with msvcrt90.dll, and the qt dll is linked statically with the runtime, or vice versa. if both are linked dynamically with the same version, then there should be no problem.

[#] Fri Aug 15 2008 15:48:40 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

You're correct. There shouldn't be a problem if they're using the same version of the library.

[#] Fri Aug 15 2008 15:57:12 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

what's nice is, oracle oci is linked with msvcrt71.dll, they claim it can work with any compiler, but i have to wonder.

i can't get my hands on a copy of whatever version of vc shipped with that runtime. it's not among the freeware releases.

[#] Fri Aug 15 2008 15:59:04 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Do DLL's have a different heap than the calling process? That
sounds... phenomenally stupid.

That kind of rings a bell, if they still do things the same way they did in 95.

[#] Fri Aug 15 2008 16:01:27 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

it was worse in win16 i think. address spaces really were more disjoint, i think. and not just in terms of segmentation. erm, DLL's had their own memory that was shared across the processes that called them. i understand that is gone in win32.

DDE and OLE, however, in win16 were based on the concept of sharing memory simply by sticking it in a DLL. they must have had to rearchitect those around a more modern IPC mechanism, but i don't know what. sucks to be them (and their victims)

[#] Fri Aug 15 2008 16:03:33 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

good point, I remember fighting and learning all that dll stupidness with win16. I know I wrote some win32 programs, but I don't think I had to fart around with dlls at the time
But at the risk of starting that static vs dynamic argument again, if you can link statically, do so, make them get more memory and suck it up.

[#] Fri Aug 15 2008 16:03:37 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

btw, if you think MS development environments are the only ones that suck, try Mac OS X sometime.

[#] Fri Aug 15 2008 16:05:36 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

in my case, the building with a DLL actally turned out to be easier for the developer (me) and bundling DLL's probably uses more memory than the equivalent statically linked solution because the linker can't do dead code elimination and i'm not actually sharing the dll's with any other process.

I do have a TOra build, though, if anyone wants it.

[#] Fri Aug 15 2008 16:27:56 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Heh.. yeah, the best libraries have neither .lib or .dll files, just .h.

[#] Mon Aug 18 2008 05:58:48 EDT from IO ERROR @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

This is why you have to reboot Windows:
(Memory use of browsers over time; flat line is at browser close)

[#] Mon Aug 18 2008 08:37:09 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

That red line is bullshit. I keep firefox 2 open for a week and my machine comes to a crawl, when it gets up to a meg of virtual memory I restart firefox and my machine becomes usable again.
Just goes to show how shitty programmers have become lately if firefox is the Big Thing.

[#] Mon Aug 18 2008 09:35:00 EDT from Freakdog @ Dog Pound BBS II

[Reply] [ReplyQuoted] [Headers] [Print]

That red line is bullshit. I keep firefox 2 open for a week and my
machine comes to a crawl, when it gets up to a meg of virtual memory I

restart firefox and my machine becomes usable again.
Just goes to show how shitty programmers have become lately if
firefox is the Big Thing.

Firefox 3 goes quite a ways towards cleaning that up.

[#] Mon Aug 18 2008 11:08:22 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

And I'd be using it too if pandora worked in it with flash 8.
Ie sucks even more though, I don't even use it except to test my apps for work, and I must say their javascript implementation is insanely slow compared to firefox.

[#] Mon Aug 18 2008 11:16:42 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

This... entertaining... piece of software keeps locking up.

I've waited for over 10 minutes for this thing to release its death grip, before killing it and starting over, only to find it freezing up again after a couple of minutes.

What the hell does it think it's doing?

It's fucking Microsoft .NET Dev Studio, 2005. Just fucking let me do my damned typing and stop trying to do whatever bullshit you think you're doing, you piece-of-crap software.

[#] Mon Aug 18 2008 11:28:07 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

It's the damned 'IntelliSense' feature.

Fucking incredible. What a completely stupid system. I disabled it by renaming the DLL responsible for IntelliSense.

[#] Mon Aug 18 2008 11:46:52 EDT from Nite*Star @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

FF2.x has memory leak bug issues ....

Go to page: First ... 9 10 11 12 [13] 14 15 16 17 ... Last