Qhimm.com Forums
Miscellaneous Forums => Scripting and Reverse Engineering => Topic started by: Dark-Raver on 2001-10-17 21:49:00
-
ok, i still have a probleme with the Run-time error "429"
ActiveX component can't create object..
It was working when i had winME, but with Win98 SE, not working... Anyone fixed this probleme?
-
I got that when I ran Ultima beta 18 on my clean Win98 install, but running JSGReg32Setup fixed it ... you HAVE done that on your Win98 install, right?
-
dude......you didnt need to do this.....this is the 3rd one.
-
yes i know its the 3rd one... But i didn't find any answer on the other tread.. And yes, i did install JSGReg32Setup and it didn't fixe it. Its weird, it worked on my Me windows...
-
Hey, you had the problem with the other runtime libraries, right? I sent them over to ya, didn't I?
I guess, the VB 6 runtimes or 'Microsoft Common Dialog' (COMDLG32.OCX), or the 'Microsoft Common Control 6.0' (MSCOMCTL.OCX; MSCOMCT2.OCX) are missing. See if you can get them at http://www.microsoft.com ...
- Alhexx
-
I know this may be a dumb question because I only program in linux, but can't you guys just staticly link your libiaries togeather or just include the OCX/DLL with the package. When I program with allegro with Linux I don't feel like distibuting the allegro.3.98.9.so all the time. (linux uses *.so files or "shared objects" basicly the same thing as an OCX/DLL) I staticly link because;
1) The person my not have permission to install libs on the system
2) I may need only a few functions
3) When a new version of allegro comes out, they will have to upgrade the shared object anyway
I do a simple "gcc --static -lalleg" with a couple
"-Dfunction1 -Dfunction2"
statements to staticly link the alleg lib and define only the functions I want. Then I strip the executible and come up with a nice managable program not depending on anything. (execpt X, but you need that to do graphics anyway)
I really don't see the probelm, unless Microsoft is *so* on crack that you can't do something like a simple static link. In that case I *demand* you drop that crap OS and move on to something a little more worthwhile.
-halkun
[edited] 109 2001-10-20 19:55
-
Okay, I see, but in this case, I've got no real choice. It'd be quite hard or hardly possible to declare functions manually in these OCX, b'cause they are new Objects for my apps, not simple functions. And, OCXs are no 'real' DLLs (AFAIK), they're Active-X DLLs. And you can't declare functions from Active-X DLLs like in 'normal' Windows DLLs.
So there's no other way 'till now...I know - it's crap. I don't like that, too... :evil:
- Alhexx
-
yes you did Alhexx... But remember it didn't work?
-
ok, btw, i would also need the list of each part what they are... Example, SA**= arm etc etc... thanx
-
3) When a new version of allegro comes out, they will have to upgrade the shared object anyway
Really? That's sh*t. (One of) the reasons for using a shared library is that, you can update the code in the library without having to update every program that uses said library.
-
...which might not always be what you want, for that matter :wink: For example, what if the proggie in question only works with a specific DLL? Not a very common problem, I grant you, but still ^^
-
You copy that specific version of the DLL into *that* program's folder only :wink: Sure, it's annoying to do that, but ... it IS a sign of a badly written program/library so either way, there's other things to worry about.
Program size isn't the only reason I dynamically link quite a bit of my code ... although I'd dynamically link the Delphi libraries too (and have 20KB EXE's, like the VC ones) if they weren't so goddamn big... but updating a shared library is a nice idea.
Actually, FMOD has a semi-nice solution to this; when their DLL gets updated if a function 'breaks compatibility' with the older version of the function it gets a new name (like FSOUND_Load_Sound_322) and includes the older version too. So older programs are still using older code ... but if the function is simply better without changing the way it works at all, the name stays the same - so older programs DO use the newer bugfixed versions when possible. Of course, the import library doesn't name the functions with version numbers so you as a programmer just call FSOUND_Load_Sound, but it IS a good solution. Slightly bigger DLL, but generally speaking it maintains compatibility well.
-
You lost me there.. Is that the answer to my probleme? :???:
-
Probably not, I was ranting on about a completely unrelated DLL :wink:
-
Ok, i understand:)
-
Linux is the same way BTW, if you update the executible you don't have to update the *.so file if the functions are the same. But can someone tell me why this is so?
VB300.DLL is needed for VB3 apps
VB40032.DLL is needed for VB4 apps
MSVBM50.DLL, ASYCFILT.DLL, OLEPRO32.DLL, COMCAT.DLL, OLEAUT32.DLL, and STDOLE2.TLB is needed for VB5 apps
1) Why isn't this backward compatible? (You can'r run a VB3 app with VB5 DLLs)
2) Why can't you saticly link this garbage togeather
3) Why can't you include these DLLs with your app?
Just wondering
-halkun
-
Well, halkun, I always wonder 'bout that problem, too. I've never said that microsoft's solution is good or even the best - I don't like that DLL crap, too.
- Alhexx
-
1) Because it's VB
2) Because it's VB
3) Because it's VB
Actually, with quite a bit of fiddling around and the right tools you *can* produce standalone VB EXE's. Of course, most people would just use a different language.
-
Cause I'm not as cynical as fice, I'll tell you why :wink:
1) You see how fice had to update his dll's when he upgraded to Delphi 6? Same reason.
2) Same as fice's answer above. (The serious one)
3) The whole point of VB was not to include those libraries :smile: Smaller apps make Msft look good I guess :wink:
On a side note, all FF7 decoding has stopped on my side cause my exams are really near and I need to study. Secondly, cause assignments have started pouring in & they'll be overdue if I don't find time to work on them soon. I'll squeeze some time if possible, ok?
-
I dont get the whole idea of dlls. Why ? Program Size ? Everybody allways sends a dll-s with the main executable. If he does not, there are problems, users dont know how to get it etc.
Newer versions ? I never seen anybody posting new dll-s, usualy when new dlls are created, also a new version of program is ready, so one downloads them both.
I dont like micro$oft. :evil:
-
this post above was posted by me (mirex). Hmmm, why was I anonymous ..?
-
DLL's serve a number of purposes ... one, you might not have the original source code. For example, I use the FMOD library for sound in the Remake engine; unless you're willing to pay for it, DLL's is all you get.
Secondly, it DOES make updating programs easier and smaller. For example, have you noticed that a lot of programs written in VC (Visual C++) are really small - less than 100KB? That's because they use the VC DLL's to do a lot of stuff, which just about everyone has. Same applies to VB programs. You *can* do it with Delphi, but not everyone has the Delphi libraries, plus there are reasons not to (you can patch the libraries yourself, for a start).
Also, updating is better for another reason; say FMOD releases a new version that supports your super new sound card. Even if the person who wrote their original program (that uses FMOD) isn't updating anymore, you can still use the newer FMOD version since it's in a separate DLL...at least, you can try it.
DLL's *are* a good idea. Not all the time, but they do have nice advantages.
-
I agree with Fice (since he's more skilled than me)(okay, and most of you, too...).
But let's not only talk 'bout these standard Runtime DLLs needed - let's talk 'bout those self-programmed DLLs... Let's take my JSGReg32.dll for example.
For those who wonder what this DLL does: It's a package of functions for Win Registry access. I'm not sure how Reg Access goes in C++/Delphi/Anything Else, but in VB you've got to declare a lot of Win API crap, play around with handles, pointers, ... So I've created a DLL which manages all that crap, so you just have to call a function 'WriteString(SubKey As String, Name As String, Value As String)' - no handles & co...
Okay, of course, I could implement all these functions (8+ pages of source) in every of my apps - but that's not practical... so *somethimes* it's better to use DLLs.
- Alhexx
-
Another way to put it is it's like using a javascript file to create a table or the top of a webpage. (I'm actually doing this.)
For v2 of my page, I'm using a .js file, which is just a text file with javascript commands, as the top of most my pages. The file has a few detection commands, but it's mostly a document.write function. It writes the top half of my main pages, but since all the pages are reading from a single file, it keeps my pages quite a bit smaller than if I put the code to the top of the pages at the top of each page.
That's just another way of explaining what Alhexx just said, so if you understood either of us, you should be able to understand both of us.
Sephiroth 3D
"One who seeks knowledge from another person, doesn't learn half as much as the one who seeks knowledge for himself." - Vincent Valentine, The Sephiroth Chronicals, Book 1: Resurrection
[email protected]
Sephiroth 3D's Final Fantasy (Currently Offline)
Sephiroth 3D's Promised Land (http://members.tripod.com/~Sephiroth3D/index.html)
-
Hehe...that's why we're called a TEAM - and I guess we're a good one :grin:
- Alhexx
-
For those who are still interested:
Ultima 0.27 (no more Betas) is out!
- Alhexx