Jump to content

Denney

Member
  • Posts

    707
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Australia

Everything posted by Denney

  1. What's even more stupid is the Driver Signing option in GPEdit DOESN'T WORK after installing the 2 updates. The option is still there in GPEdit but doesn't actually work.
  2. I'm p***ed because I tested Office 2007 and we got NOTHING. I've been beta testing with Microsoft for A LONG time and I don't expect to get anything but when something this big gets given out to testers and the other, almost equally big, testers get nothing. Ah well, crap happens I guess.
  3. WOOHOO!! I've been waiting for this day! Time to crack open the beers and celebrate!! Looking forward to the slew of new features to appear in the next few versions...
  4. Ah ok. Thx Sonic. I only use my scripts on XP so the compatibility thing isn't an issue. So basically, the only difference is one is command line based registry editor and the other is a GUI based registry editor. Seems simple enough.
  5. @Avneet: That command currently won't work because the current code cannot find the "regedit" file. That's what we've been discussing.
  6. I agree. I'm one of those "has to stay updated" people. I would love to know how to make the micro installer myself. I could probably do it myself, just a guide would be a lot nicer (not even a guide, just some directions would be nice). Plz... Edit: Can anyone explain why, when I enter my LEGIT, RETAIL Premium edition serial number, it spits out this error: The serial number you have entered is a valid Nero serial, but is not valid for this application. I'm using the English Nero Micro package. Edit2: Nevermind. It seems, silently installing the micro package and then running the program won't accept my key. Adding the key straight into the registry on the other hand and it'll work like a charm... How strange. :S
  7. I agree with mritter that it will make it harder to keep our modifications but hey, if I'm making my own mod's, I know how to re-apply them if things still don't work... It's true though. Most people shouldn't edit the code to fix things... v5 isn't a final release after-all. The only reason I do it is to try and fix the already existing problems in the hope to make your life easier. Anyway, good luck with the fixes and I'll stop posting code now.
  8. I mean to add a new configuration option like "condition" but the passes the content to the FileExists() function. The end user would need to specify this path but maybe WPI could "attempt" to guess the correct path (that would require a fair bit of logic code though).
  9. @Dje: Yes you will and that is why I have a FileExists() condition for every one of my programs in WPI. Granted it uses up my "condition" statement but hey, it makes sure the programs are there (and I still have the greyed-condition to use). If we're gonna stick with the Shell.Run() command, I'd suggest having an option in the configuration file for an actual FileExists() condition that the user can specify. More work the end user but does prevent these errors. @mritter: Yes, thankyou heaps for your work. At least this is better than nothing and I'm greatfull. WPI has saved me HEAPS on time in making my business run smoothly. Thankyou both (mritter and Kel) for the excellent work!
  10. I have mine setup like this: ReturnCode = InstallShell.Run(cmdLine,1,true); if (ReturnCode) { WriteLogLine("Cmd1 Fail (returned code "+ReturnCode+"): '"+cmdLine+"'"); programs[i].fail=true; } else { WriteLogLine("Cmd1 Success (returned code "+ReturnCode+"): '"+cmdLine+"'"); programs[i].success=true; } Granted it doesn't always return the correct code but at least if gives you an idea. NOD32 and TortioseSVN are 2 programs that return non-0 return codes when they finish. I think this is better than the old way because at least the programs get executed rather than just bypassed.
  11. @Dje: What is the actual "rundll32" command you are using in WPI? Edit: The reason the command doesn't work is because WPI surrounds the entire command in double quotes. Comment out the "ExtractArgs" line and replace the InstallShell.Run line with: InstallShell.Run(cmdLine,1,true); and it should work.
  12. You're right. They are. The Shell.Run command returns the return code of the program it's executing and not of the Shell.Run command itself. Basically, it just passes the return code through. @Dynaletik: Your first problem, of the config file, are you using RC2 or RC1? RC2 fixes a problem of it not installing based on order number. Your second problem is the reason Dje and I are posting here. It has to do with the way WPI v5 handles command arguments (it only searches for -'s and /'s and XP-AntiSpy uses +'s). Personally, I've commented out the FileExists() code because I've added a FileExists() condition to ALL of my programs. Maybe make that another config file option? So the user can specify the file to look for before running the install? Or hell, make it optional. Edit: Better idea, make 2 config file options... 1 for the command to run and 1 for the arguments to run with it. Sure, it'd break the current configs but it would make the FileExists() calls work.
  13. @Dumpy Dooby: You just beat me to it. I was just about to post that suggestion. Makes things look a lot cleaner (removes a lot of disabled checkboxes...).
  14. The problem with that is that each program's return code is different. It's up to the program to return a return code so the actual return code would only be usefull if the user knew what the return codes meant. Would be a better idea than the current implementation though. Maybe checking for a "0" return code to indicate success (most programs return 0 on success)? Edit: Just an update on my post above (#16), I managed to fix this by changing line 227 in program.js from: progspercat.sort(SortByProg); to: progspercat.sort(SortByOrdr); I just loose the ability to sort programs by name when displaying them.
  15. @Dje: I agree. I have many "cmd" scripts that I call and I pass the path of WPI to them like so: "%wpipath%\software\someprog\someprog.cmd" "%wpipath%"
  16. I was waiting until the new version came out to report this as it happens in v4 aswell... When setting ProgB to depend on ProgA and setting BOTH to default, only ProgA is selected. ProgB must be selected manually, although it is set to be default in the config file. Edit: I just realised that it's because of the way the items are ordered in the config file. ProgB's MUST appear AFTER ProgA in the config.js file. In other words, the ID must work out to be "higher ranked" for ProgA than ProgB. Eg. ProgA [with ID ProgA] and ProgB [with ID ProgB] = both checked. ProgA [with ID STPD] and ProgB [with ID DaemonTools] = STPD checked but DaemonTools NOT checked. Edit2: I was wrong. It's not sorted on UID... it's sorted on name (but you already knew that). So the names need to be ranked accordingly.
  17. Seems the easiest way it to use this: Do While Not myProcess.HasExited Application.DoEvents Loop Not the nicest way but it'll do.
  18. I've created a program that, when clicking a button, runs another process (in this case, nLite) and waits for it to exit using the Process.WaitForExit() method. The problem is, the GUI off my program freezes up while it waits for the procress to finish. Eg. Sending my program behind another problem and bringing it back again makes my program go white (needs to repaint itself but can't because it's waiting for the other process to finish). I've tried using a new thread to run the process in and that leaves my process to repaint itself if needed BUT my program won't wait until the new thread is finished before doing everything else. That's the problem. I've tried Thread.Join() but that has the same problem as initially stated. Any ideas on how to work with this problem cause I'm stuffed?
  19. Heh. well i'll be. Never thought of that, but then again, all my iso's are only created with uppercase flag set. Nice catch.
  20. I'm just curious if anyone knows of the advantages/disadvantages of the two commands: REGEDIT32 /S "SomeFile" REG IMPORT "SomeFile" Anything?
  21. Could you please post your winnt.sif file (without the product key of course) so we may look and see if the problem lies there. 1) This doesn't matter. 2) Just make sure no "winnt.si_" file is in the I386 directory. 3) This doesn't matter.
  22. The new version looks awesome... GOOD WORK BASHRAT! Can't wait for it to be released to play with. I've been holding off on creating my May 2006 CD just for this. Can't wait. It looks so much easier to use. As I said, great work Bashrat!
  23. OK. I can't see any "quasi-marketing claims" in the text that you quoted. All of that text is stating true facts and they're to the point. There's no marketing there. I don't buy or test a product because there are exclamation points in the product description! Oh look, even I used an ! then! As I said, most of the issues AREN'T related to the actual DriverPacks, hence no known issues with the DP's. Those known issues are upon release of the DP, not updated every day so Bashrat thinks he's fixed all known issues but really hasn't. He just doesn't know it when he states there's no known issues... You expected "high quality" from a product originating from MSFN but you didn't actually find the product at MSFN but through www.driverpacks.net instead. How then did you come to your conclusion of a high quality product from the beginning? You contradict yourself there.
  24. What "quasi-marketing claims" are you referring to? Nowhere does Bashrat guarantee this will work flawlessly... In the documentation for the DriverPacks he states "Testing is very important! Always do some testing before you’re (re)installing Windows on your o-so-important workstation!". That should be the first indication that the DriverPacks might not stand up to your high quality standard. Also, you originally said that you expected the quality of the rest of the "products" that come from MSFN BUT you then state that you had never visited the DriverPacks forum until AFTER you had donated and tried it... How then did you come to the conclusion that it should be to the "high quality" you seem to expect from anything from MSFN forums? Most of the flaws with the DriverPacks you'll find AREN'T actually the DriverPacks... They're either user error or driver error or hardware error. The DriverPacks only extract the drivers and make them available to Windows without the expense of having to do it manually yourself. I, like many people, never expected this to be a plug-n-play solution. It doesn't state anywhere that it is. It's merely and ATTEMPT at making creating a UXPCD easier by removing the common trial of installing device drivers using Microsoft's methods or, shock horror, manually! You're analagy to a car repair shop puzzles me to... If you got the car back (your UAXPCD) and it worked properly (DriverPacks worked) but there were some small problems related to other components (vendor hardware) in the car, would you expect to get a full refund? I think not. Also, it stated nowhere that you need to donate to use this software. End of another rant. I love this stuff to much.
  25. I've been on both sides of this bench (as a user and developer) and I can tell you now, if you don't do your research first, you will get burned. There are plenty of topics on this very board that state the flaws/problems in the packs... Did you expect all those problems to not apply to you? Did you think that all these problems are user errors and not related to the packs in any way? I wouldn't DARE go bashing Bashrat for his hard work. I would never demand my "donation" back even if the programs didn't work. In all, I wouldn't donate until I was sure it worked first... If you spend some time with all of these tools, you can generally fix any errors that crop up. Reading the OPK will take more than 80 hours to master, trust me. Those 80 hours would be better spent trying to resolve and fix these errors rather than giving up completely and starting over yourself. These small programs are a godsend to people who can research what they're doing and know that not everything is perfect. Think of it this way, the worst Bashrat's packs can do is not install a driver (for $25 DONATION) but Windows can open you up to hacker takeovers of your computers (for over a hundred dollars REQUIREMENT!). Hard to figure the math in that eh... Anyway, that's my rant over (sorry if I seem a little harsh, I have the flu at the moment and life's just p***ing me off). Wait till the new DriverPacks are out, try again and if it doesn't work then, let Bashrat know and I'm sure he'll try his hardest to fix it WITHOUT payment... He's doing a noble service to the community along with quite a few other people (Ryan, nuhi and many others). I commend them for trying to make our lives easier!
×
×
  • Create New...