For those that don't read the Programming forum, I have released version 1.0 of my Empeg Logo Editor. It can be found at http://www.jps.net/tfabris/logoedit.htm. Enjoy!

___________
Tony Fabris

Here's an idea, Tony. Along with the program zip file you could supply the exact color palette you used for the startup logos. This would eliminate any confusion and users wouldn't even have to go through those steps in the FAQ article.

Just a thought...

DiGNAN

Here's an idea, Tony. Along with the program zip file you could supply the exact color palette you used for the startup logos. This would eliminate any confusion and users wouldn't even have to go through those steps in the FAQ article.

Actually, if you use my logo editor, you don't have to do any of the steps in the FAQ article. You can just start painting, or you can just paste from any bitmap. You don't need a palette or color reduction. The FAQ is kind of obsolete now (although I did recently touch it up a bit when I linked my logo editor).

The exact color palette can be gotten by copying the default image to the clipboard and pasting it into your paint program. Now you can use the paint program's tools to build a palette in its own format.

Besides, the color palette in my logo editor is now user-configurable. After the first run, the values are in the .INI file, and you can get them from there if you want.

___________
Tony Fabris

Oops, I just noticed it's not the version you first talked about in the other thread. I believe that one was hindered somehow, wasn't it?

Well, I just used your fantastic program to make my own image and load it on the empeg. FANTASTIC JOB!! I think this is an incredible piece of software. Easy to use, functional, and it works!(always a plus)

I still sort of like to use PSP to edit the images, but you made this easy with your import/export feature. Great job!

So after seeing all the stuff I missed the first time, I have only one suggestion: do you think you could make the "Open" box more like the windows explorer type that opens for most programs? The type you included is the kind that always annoys me because it's a bit difficult to navigate. But this is a minor annoyance.

GREAT JOB TONY!!

ps-I attached the simple image I made with Tony's editor. Explanation: it's my liscense plate

DiGNAN

You sure it is spelled right ?

Cheers,
Hans


Mk2 - Blue - 080000431

I still sort of like to use PSP to edit the images, but you made this easy with your import/export feature. Great job!

Thanks, glad you liked it.

Note that for most programs (including PSP) you don't even need to use the import/export menus. You can just CTRL-C and CTRL-V to copy and paste the images between the two programs.


do you think you could make the "Open" box more like the windows explorer type that opens for most programs? The type you included is the kind that always annoys me because it's a bit difficult to navigate. But this is a minor annoyance.

I'm currently struggling with this. Here is the situation:

I prefer to distribute my programs in as simple a format as possible. I want you to be able to just unzip-and-run, and not worry about installs or DLLs or anything like that.

To that end, this program was written in 16-bit VB3. The beauty of VB3 is that it runs fine on all the new Windows platforms, but its runtime DLLs are small and can be included in the same folder as the EXE. For instance, in my distribution, the two runtime files (vbrun300.dll and cmdialog.vbx) are sitting right there in the same folder and it works great. No need to do a complicated, bloated installer that has to version-mash with crap in your System folder.

But the problems is that since it's a 16-bit program, it can only use the 16-bit "open" dialog. That's the box that irritates you. It irritates me, too, since it won't show long file names.

So, the only option is to port it to 32-bit. I've got two ways to go about it:

1) Do it in C. I tried that first and gave up. Dealing with bitmaps and device contexts is a major pain in the ass in C. Yes, I could do it (I've done it before), but if I had, I'd still be debugging the first prototype instead of having already delivered a fully-featured and polished version. VB development is just so much faster and simpler. All the under-the-hood stuff for dealing with the bitmaps and the clipboard is handled for you. For instance, the command to export a file to a BMP was literally one line of code in this program, and it would have been over a hundred lines if I'd done it in C.

2) Port it forward to VB6. In fact, I've already done it and it works great. There's just a problem with VB6...

The problem with VB6 is that it's bloated. The VB6 runtime library alone is over a megabyte. In addition to that, you have to install a bunch of bullsh*t OLE libraries along with it, making the distribution huge. This irritates me to no end, since I don't even use OLE in the software. This is pure arrogance on the part of Microsoft, making us drag this crap along every time we install a program.

And not only that, the OLE stuff (heck, and even the runtime DLL and the common control OCX) are version-control nightmares. I've seen systems actually quit functioning because of mismatched OLE files. I don't want the weight of that problem to be on my shoulders if I can avoid it.

Sure, microsoft provides their own VB6 runtime installer to handle that crap for you, but that doesn't make it any less bloated. And since I'm using the common control OCX, I'll have to distribute that and version-check it anyway (on one of my test systems I got an "OCX out of date" error because although it already had the OCX, it had an older version).

Still, I want to distribute it in a 32-bit-aware version, and I'm investigating ways to do that easily right now.

One option would be to dump the OCX and call the common dialogs directly via the Windows API. Then I could at least distribute just my zipped VB program and have a corresponding link to the VB6 runtime installer. That way, I'd be able to still have a small, ubloated download for everyone, and only the people who don't have the VB6 and OLE runtimes would need the extra install. This is attractive and I will be investigating it more closely.

Another option would be to follow up on an ad I saw in Dr. Dobbs once. They claimed to be able to turn your DLL-needin' VB program into a stand-alone executable that doesn't have any external dependencies. In effect, statically linking your runtime libraries and OCXs to the EXE. I don't know how well this works or how much it costs, but I'll be investigating that first.

___________
Tony Fabris

Another option would be to follow up on an ad I saw in Dr. Dobbs once. They claimed to be able to turn your DLL-needin' VB program into a stand-alone executable that doesn't have any external dependencies. In effect, statically linking your runtime libraries and OCXs to the EXE. I don't know how well this works or how much it costs, but I'll be investigating that first.

Holy sh|t, it works.

Bit Arts Fusion. I think my company is going to buy this product for us.

I just created a copy of the VB6 version of LogoEdit, plus the following linked dependency files:
1,384,448 MsVbVm60.DLL
140,288 ComDlg32.ocx
17,920 STDOLE2.TLB
598,288 OLEAUT32.DLL
164,112 OLEPRO32.DLL
22,288 COMCAT.DLL
147,728 ASYCFILT.DLL
27,136 ctl3d32.dll

Normally, that's a total of about 3 megabytes. Now it's a single LOGOEDIT.EXE and it's only 1.2 megabytes total. Runs perfectly on a bare-bones fresh-formatted Win95 system. Suh-wheet. More investigation and testing is needed to be sure about this, but... whoa, this is pretty cool.

___________
Tony Fabris

*Very* nice piece of work Tony. Thanks

Henno
mk2 6 nr 6

Thanks, glad you liked it. If things go well today, there might be a 32-bit-aware version of it up tonight.

___________
Tony Fabris

there might be a 32-bit-aware version of it up tonight.

Yep, I just read your post about it. Nice that there still are people around who can bring order into the MS chaos.
Also goodto see that Dr Dobbs is still around (around again?)

Henno
mk2 6 nr 6

Also goodto see that Dr Dobbs is still around (around again?)

Funny thing is, when I went back and found it again, it wasn't an ad from Bit Arts. What I'd seen was an ad for ComponentSource.Com, and part of the ad was a screen shot of their front page. In the listing of components was a short blurb about Fusion. For some reason, I had actually been reading the text of the screen shot of the web site, there in the magazine. That's where I found it.

___________
Tony Fabris

Great work Tony! I don't know how you have so much time to do these projects. This one is fantastic.

First time i ran it and did the upload, I didn't think it worked. Ran it again and sure enough, after a re-boot it had my images there. Top stuff.

Could you add a part to the uploader which reboots the empeg? My Mk1 (haven't tried Mk2 yet) just sits there blank.

Murray 06000047
____________________

Could you add a part to the uploader which reboots the empeg? My Mk1 (haven't tried Mk2 yet) just sits there blank.

Yes, I would like to do that, and for precisely the same reasons.

Only problem is that I don't know what bytes to send to the empeg to make it fully reboot all the way back to the beginning of the ROM loader. I asked in the Technical forum, and some folks suggested that "r(cr)" was the ticket. The only problem is that this just restarts the player not the boot loader.

I tried reverse-engineering the commands that the EmpegUpgrade.exe sends to the empeg. I did this by running hyperterminal on a second machine and running EmpegUpgrade.exe on the first machine. I get a stream of interesting bytes, but when I plug those into the uploader code it doesn't do anything.

I have posted that question on the technical forum in hopes that Hugo would respond, but he hasn't. I think I'll e-mail him directly now.

___________
Tony Fabris

More investigation and testing is needed to be sure about this, but...

Damn, it's not a silver bullet.

One of the problems is that on a fresh-formatted Win98 computer, the file OLEAUT32.DLL is present, but it's not a recent-enough version to make MSVBVM60.DLL happy. So even though I "fusion'ed" the correct OLEAUT32.DLL file to my executable, the older one installed on the system takes precedence and I still get the out-of-date file error message.

So this "fusion" app, although promising, is kind of useless for my purposes. I was hoping it would save my app from DLL hell, but it doesn't. And my app is a pretty darn simple app, it doesn't have any complicated dependencies, just whatever dependencies VB has natively.

I could still distribute it as it stands now, and link to the microsoft VB6 Runtime installer. But so far there isn't a compelling advantage to move to VB6 except for the new file dialogs. And since the current 16-bit file dialogs work OK (they're just mildly irritating now), I don't see a reason to add the extra megabytes of bloat.

I find it odd that Fusion doesn't solve my problems because that's the very root of what they're trying to do: Make it so you don't have to distribute the VB6 runtimes.

___________
Tony Fabris

One option would be to dump the OCX and call the common dialogs directly via the Windows API. Then I could at least distribute just my zipped VB program and have a corresponding link to the VB6 runtime installer. That way, I'd be able to still have a small, ubloated download for everyone, and only the people who don't have the VB6 and OLE runtimes would need the extra install. This is attractive and I will be investigating it more closely.

This shows you how to do 32-bit common dialogs without DLLs or OCXs (vbAccelerator is an excellent site).

As to VB6 needing all those OLE DLLs, it doesn't really have much choice seeing as the whole of VB6 is based on COM (one of the many alternative names for one incarnation of OLE). It is painful though to write a simple app that compiles to a couple of tens of kilobytes, only to have it bloat to several meg when you distribute it.

At least you aren't struggling with VB4...
(the less said about VB4 the better)

That tool from BitArts looks interesting, but I think I would want to do some testing before relying on it!

Thanks Tony for all your hard work, I never did get the time to complete my logo editor/uploader.

__
Unit serial number 47 (was 330 in the queue)...

I could still distribute it as it stands now, and link to the microsoft VB6 Runtime installer. But so far there isn't a compelling advantage to move to VB6 except for the new file dialogs. And since the current 16-bit file dialogs work OK (they're just mildly irritating now), I don't see a reason to add the extra megabytes of bloat.

Does VB6 not make things faster? I would have expected some speed-up moving from VB3 (assuming you dim all the variables with datatypes and use longs instead of integers). The preview window takes about 10 seconds to refresh on my PC and pasting takes about the same time (but probably just because it is refreshing the preview).

__
Unit serial number 47 (was 330 in the queue)...

This shows you how to do 32-bit common dialogs without DLLs or OCXs (vbAccelerator is an excellent site).

Thanks for the link. I might go that route.

What would really be awesome is if there were some sort of "generic reverse thunk" mechanism so that I could call the 32-bit dialogs from my 16-bit program, have it return the strings, then call the 32-bit function to pull the short file name versions of those strings.

Then I could use short file names internally to my program, but have dialogs that showed the long file names properly.

I wonder if such a mechanism exists?

___________
Tony Fabris

Does VB6 not make things faster?

Yeah, it did. Somewhat. Not enough to justify that bloat, though.

The preview window takes about 10 seconds to refresh on my PC

The preview window is strange, it seems to depend less on the CPU and more on the video drivers. It shouldn't take that long. On my 233 it only takes four seconds to display/refresh the preview window. Are you running in 32-bit color or 16-bit color?

I've thought about ways to improve its speed, and I might try those techniques someday. We'll see...

pasting takes about the same time (but probably just because it is refreshing the preview).

Right. If you turn off the preview window, pasting should be nearly instantaneous.

___________
Tony Fabris

I wonder if such a mechanism exists?

Not that I'm aware of, attempting that sort of stuff was what made VB4 such a nightmare...

__
Unit serial number 47 (was 330 in the queue)...

I'm running in 32-bit colour. I just tried 16-bit, it makes no difference.

This on a PII300 with an STB Velocity 128.

Unfortunately once you start trying to speed up things like this in VB you end up basically writing C++ in VB (i.e. every line of your code ends up calling an API call or trying to simulate some operation that would be easier to do in C++). As I found to my cost, the code that was in my aborted logo editor was getting really nasty.

__
Unit serial number 47 (was 330 in the queue)...

One way to reduce all this dll hell stuff is to move to something like Delphi... =)
I believe moving from VB to Delphi is quite painless (I've never used VB in the first place, but I use Delphi all day at work)

Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)

You've got a point about Delphi. I just don't have a copy of it to develop with. Aren't they coming out with a Linux port of Delphi? That'd be cool- writing a Windows program that magically compiles under Linux.

___________
Tony Fabris

Hmm, moving to Delphi means learning Object Pascal which is very different to VB. However it would have been great if VB had gained the ability to in-line the code like Delphi does. VB6 is really compiled (it uses a version of the VC++ backend), but they never when the extra step.

It will never happen now, as the next version of VB will be part of the .Net platform. If Tony is worried about bloat now, just wait. The .Net runtime is likely to run to many tens of megs rather than 3 meg...

(though of course the runtime will be built into future versions of Windows anyway, it doesn't help Win9x and WinNT4 users, who will have a very large download to do)

__
Unit serial number 47 (was 330 in the queue)...

writing a Windows program that magically compiles under Linux

Hmm, until it doesn't of course...

In the whitepapers for .Net MS introduce a new acronym, IJW. This stands for "It Just Works".

Probably more appropriate would be IJWUEWYRNIT.

(It Just Works, Usually, Except When You Really Need It To)

__
Unit serial number 47 (was 330 in the queue)...

I feel qualified to answer this one, (as I went to the Borland UK conference a few weeks ago... (And saw the very thing working =)
They are bringing out Delphi for Linux (x86) and down the line C++ builder for Linux. The visual component library (VCL) has been rewritten as a cross platform library (called CLX and using QT for the visual bits). They have also added things like Apache support so you can recompile ISAPI dlls into Apache shared objects (at least that's the idea).
Delphi 6 for windows will allow you to use either the VCL for windows only, or CLX for cross platform.

All in all, rather cool stuff... =)
(I do have a basic empeg image tool written in delphi, which created the files for the old display program. I might have to update it now... =)

Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)

Borland are actually trying to get VB users to switch to Delphi now on the grounds that they will be able to port to Linux soon (Due to the very unlikely nature of VB for Linux).
They seem to think it's not a large leap to move to Delphi (I've never used VB though... =)

Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)

Off Topic a little, butta ... Any ideas on license form and price of the Linux Delphi version. Kinda interested in that really ... Been out of the loop as far as programming goes for far too long now. Christ the last thing I learned was Cobol 85 and RPG ... Talk about ancient.

Okay I did some C coding on linux since but that was just because I really HAD too ...

Cheers,
Hans


Mk2 - Blue - 080000431

I'm not really sure, but I think it will follow the normal borland pattern, which is standard (The basics), professional (Database access) and enterprise (Client server 3 tier)...
The standard level of JBuilder and C++ builder (On windows) has been released for free (I think) so it's resonable to assume that the basic Linux version will be either free, or just cheap.
However, it's possible they will give away the compiler, and try to get you to buy the Environment bits... =)

All should be clear by the end of the year (when it should be out... =)

Jazz
(List 112, Mk2 12 gig #40. Mk1 4 gig #30. Mk3 1.6 16v)

Probably more appropriate would be IJWUEWYRNIT.
(It Just Works, Usually, Except When You Really Need It To)

or maybe IJWBDNUFMCS
(It Just Works But Do Not Use For Mission Crittical Stuff

Murray 06000047
____________________

Version 1.1 has been released at the Empeg Logo Editor home page.

This one is a 32-bit application written in VB6. If anyone had trouble running the previous version, try this one and see if it's any better.

Note that this requires the VB6 runtimes (ick ick ick!), but I decided the improved speed and 32-bit file dialogs were worth it. Download location for the runtimes is linked at the web site.

Improvements from the previous version:

- Faster.
- 32-bit file I/O dialogs.
- Bugfixes.
- Uploader now reboots the player when the upgrade is done so you can see your new logo.

For the complete list of changes, see the readme.txt.

Let me know how it's working on various systems?

___________
Tony Fabris