square bullets

Generally save time, but the projects are usually done by more than one person (last distribution list I counted for the project I'm on now was over 250).

It takes about ten minutes just to build a (two state) sim model for the *small* corner of the chip I'm working on. The last project (similar chip, different unit) would take an hour on the largest system I had access to and another three days on a pool of hundreds of systems for basic regression, just to make sure nothing major got broken. ...and there are another eight or ten units and chip regression going on at the same time.

Even with the differences in the scope of our projects, I think I'd use something like CVS for version control in a small one-man operation too. It's too easy to get something out of sync. BTDT.

--
  Keith

Speaking of PDFs, the PHB called me into his office the other day, and shows me an email from some client, who has attached a couple of PDFs, and asks if we can edit them. I says, "Well, as far as I know, you can, but you have to buy special software." So, the PHB plunks down $299.00 and I download the full Acrobat Standard.

Turns out, it _can_ edit a pdf, _IF_ the pdf was originally created with Acrobat 7.0, and you have the same system fonts that were used when it was created. Other than that, it's useless. Well, It can create PDFs, just like PDF995 does for free. So, I called the business office of Adobe, and said, "I want my money back!" The gal said, "OK, just print out our Letter Of Destruction:

, fill that out, and fax it in, and we'll credit your account within

48 hours." And she was all cheerful about it, like, they can afford to refund a few dissatisfied otherwise-customers' money, because they're raking it in hand over fist from the rubes.

One interesting thing - I called tech support, and said, "OK, I've got the software, now is it or is it not possible to edit an existing pdf file?" He says, "Yes." I said, "How?" and he said, "Our fee for continued tech support is $39.00..." I cut him off. "WHAT!!!!!!?!?!?!?!? I just plunked down three hundred bucks for this software, and now, in order to get it to operate as advertised, you want me to pay you MORE???? Screw That!" Which is when I called their main number again, and it was as simple as pressing "2" for the refund department, which turned out OK, see above.

THanks, Rich

Rich,

You might want to check out these guys:

. You can try it out for free...

Less than 1% would be my guess.

--
Service to my country? Been there, Done that, and I\'ve got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

Older versions of Windows allowed you to type scanreg /fix from the C: prompt to fix a lot of problems. I am looking at a program called "Brute Force Uninstaller" that lets you write scripts to remove unwanted programs cleanly, and leave no trail in the registry. Its a freeware package from

where you can find some other free and useful software tools.

--
Service to my country? Been there, Done that, and I\'ve got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

No need - I installed PDF995 months ago, and it's been working just fine. :-)

Thanks! Rich

Hi Joel, That looks interesting. Have you used it yourself?

...Jim Thompson

-- | James E.Thompson, P.E. | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona Voice:(480)460-2350 | | | E-mail Address at Website Fax:(480)460-2142 | Brass Rat | |

| 1962 | I love to cook with wine. Sometimes I even put it in the food.

IFF you know what registry keys to edit. The registry is simply a horrible design. Note that no special tools ae needed for Linux (or OS/2). Just delete the programs that aren't wanted.

Editing Window's registry is equivalent to playing russian roulette with your data.

--
  Keith

I've never quite understood why we had to switch to a registry approach.

For years and years INI files sufficed quite nicely. Some of my "golden-oldies" work just fine under XP with just an INI file.

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
|  Analog/Mixed-Signal ASIC\'s and Discrete Systems  |    manus    |
|  Phoenix, Arizona            Voice:(480)460-2350  |             |
|  E-mail Address at Website     Fax:(480)460-2142  |  Brass Rat  |
|       http://www.analog-innovations.com           |    1962     |
             
I love to cook with wine.      Sometimes I even put it in the food.

There is also primoPDF and PDFcreator, I stopped using 995 since it kept calling home for adverts/sponsors, Primo works just fine

martin

Oh, but it's such a good place to hide tracking information, timestamps for product expiration, and such things. It keeps BillG in Chinese food.

--
  Keith

I've edited the registry for years with no problems. The idea is to create a script to clean up all of the computers I repair for disabled veterans to remove all traces of common programs where I can't just reformat the hard drive and start over. Remove a program once while writing a script and save the script to the workshop server for the next time. Then combine a number of scripts to save time. Start the program and let it run while I'm busy doing something else. Its a lot faster to fix a few problems than to start over, and if I can let a program do most of the work its even easier.

I have collected the install disks for a lot of software that i have to remove so I am going to take a freshly installed copy of the OS, save a text copy of the registry. Then I will install the program and save another text copy of the registry. I will locate all the new and changed files, and write the script for that program.

--
Service to my country? Been there, Done that, and I\'ve got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

"Jim Thompson" wrote in message news: snipped-for-privacy@4ax.com...

For a single user, the only particularly good benefit that I can think of is that it makes backing up programs' settings somewhat easier, because they're all held in one place. When you get into company environments with many users with different hardware configurations, it's a lot easier to configure software when all of their settings are in one known spot (the registry) rather than in an unpredictable directory somewhere (since different machines and users will typically have their software installed in different locations).

INI files don't allow multiple levels of hierarchy, and while I'd readily admit that software guys seem to often like to impose somewhat artificial hierarchies, software development today does consist of a lot of "drag and drop" design, and if each control needs to store its own settings somewhere, it's a lot easier for that control to have a specified place to do so (the registry again of course) rather than somehow having to interact with the "main" program whenever settings need to be stored. A good example would be, say, a toolbar button control that saves its position and what all the buttons on the toolbar are -- it's a lot cleaner if the toolbar button control class worries about saving all that information and the program it's a part of doesn't need to know. Although I wouldn't suggest it's pretty, having 50 different registry branches to store all this information is probably better than having 50 different .ini files floating around your hard drive.

The registry approach was created in an attempt to solve some real problems with INI files, although I think the solution wasn't as good as was initially envisioned. If XML had already been around when Microsoft was cooking up the registry, perhaps they would have used that instead.

Umm... are you forgetting all those .fubar_rc files that litter a user's home directory in *NIX? There are plenty of times when they're not documented either and -- unlike Window's registry or even .Ini files! -- there's no agreed upon standard for what their format ought to be; every software author has to "roll their own" standard or use one of the dozens of different implementations that are available out there. Yecch!

The various Linux desktops even have a hard time agreeing how a software installation routine is supposed to register a new program with their "Start" menus. Uggh... But it is this "registration" that makes it ill-advised to just delete a program executable in Windows OR Linux -- when you install a control of software package, you're telling the system, "I'm ready to run and interoperate with you!" and just deleting the executable doesn't remove that "annoucement" (a registry entry in Wndows, some .config file in *NIX); obviously not a good idea for a robust system.

That's why they make it easy to back up, and the system even does so automatically for you at potentially "dangerous" spots (such as when you install a new device driver).

Hi Jim,

"Jim Thompson" wrote in message news: snipped-for-privacy@4ax.com...

No, but I have used (and own a copy of) Foxit Reader Pro (after trying the

100% free version for awhile). It's not perfect -- it has several non-negligible bugs, such as not always remembering toolbar positions, search becoming very slow in a small number of documents for some inexplicable reason, printing not working correctly with a small handful of printers, etc. -- but in at least 99% of the cases it's as good as Acrobat Reader and the ~1.5MB footprint (and no installation required -- just run the executable directly!) makes it look quickly on any machine. That's why I originally tried it -- we have some old lab machines that are something like 600MHz Pentiums, and occasionally I'd want to pull up a data sheet on one and Acrobat Reader 6 is *painfully* slow to start-up and run on such machines.

---Joel

Apparently you've never heard of RPM's or Slackware packages. There's even a utility that comes with Slackware that will make a "real" Slackware package from source. You still do "configure", and "make", but then you run "checkinstall", which creates the package and installs it. It keeps all of its records in /var/log/packages, which has a file for every package installed on the system, telling removepkg exactly what to delete.

And about your .fubar_rc files, if I uninstall fubar, and it doesn't clean up its own config files, at least I know where they are to delete them myself.

I just don't trust any S/W that does stuff without telling me what it's doing. Or worse, does stuff I didn't _tell_ it to do.

Thanks, Rich

Hi Rich,

Last I was playing with such things (over a year ago), getting start menu icons wasn't something that worked on all the (popular) desktops out there, but I suppose that since desktops seem to have been boiled down to KDE and Gnome for probably 90+% of users, this has been sorted out? What you're describing sounds like a step in the right direction, although it still doesn't pass the "grandma" test of just being able to click setup.exe and go.

Keith was claiming that he could just delete a program's executable on *NIX compared with the hassles of Windoze's add/remove programs routine; what I was trying to point out was that *NIX surely needed such functionality as well. The "removepkg" bit is new to me, but appears to perform that function.

I'd say the chance of *not* being able to find a Windows program's setting under HKLM and HKCU/Software/Company Name/Product name is only marginally higher than not being able to find a *NIX's program's seettings under ~MyName. :-)

That's reasonable enough, although any of the mainstream Linux distributions installs plenty of daemons during a "default" install just as Windows has plenty of start-up processes by default. Granted, In Linux it's probably a little easier to track down where a process came from compared to Windows. (In particular, it seems like almost no one in Windows *wants* to use the Startup, preferring to use the registry auto-run keys instead.. .it's hard to believe this isn't done as a slightly sleazy attempt to make control of one's own machine a little bit harder...)

---Joel

In article , Keith wrote: [....]

Its better to create your Makefile with fake targets for that sort of thing.

You can then type:

make clean to remove all temp files make all to do a total debug build make flash to make the shipped result (yes it goes in a flash)

I use a combination of make files and batch files. There are some things that make just doesn't do well. For these, a batch file that runs make works better.

A GUI with only one button:

------------------- ! ! ! ------- ! ! ! DO IT ! ! ! ------- ! ! ! -------------------

Is what is needed here.

I've only ever worked on one project that used purchased CVS tools. It got totally screwed up. We had one "programmer" who would "get" a file, copy it to his Mac and then "put" it back unchanged. Later he would "get" the file and over write it from his Mac and "put" the new version. This totally screwed things for everyone.

Since then it has been more like this:

Dave: I need to work on XYZ.A51 Ken: Ok here's a CD with it on ..... time passes ... Dave: I'm done with XYZ.A51. Here's the changed version.

This along with making a full backup of the source at all important points and always putting our names and the dates in the comments has worked well for us.

--
--
kensmith@rahul.net   forging knowledge

In article , Andrew M wrote: [....]

So, what is Microsoft paying these days?

--
--
kensmith@rahul.net   forging knowledge