scp2

What's missing here is a function "delete account and quit membership respectively"

I have to admit that I'm really getting frustrated with those packs in the meantime. What others refer to as "stable" is a mere nightmare for me and obviously others as well. Not meant to offend anybody - just neutral - but from an economic point of view this is a real waste of time and money, no proper organisational structure apparent, bad documentation (if any & this forum is a mess) and kind of see-saw development. First those annoying syntax errors in the scripts time and time again, then that wrong hardware detection which detects hardware not even installed causing very time saving BSODs and last but not least the driver integration which on the one hand lets the text-mode driven setup routine work flawlessly but on the other hand doesn't integrate those drivers properly into Windows. Not to mention the errors once wiped out and later introduced again. I do know it's not a small "project", yeah, and it has been and will be hard work and I say thank you (really) for the things achieved, they must no be forgotten but - sorry - this is not handled as a project at all, it much more gives the impression of an adventure playground. And don't say "beta, beta". Beta is a matter of fact in software development, yes, but not an excuse for everything. There is no need for several years of beta before one stable, final, almost error free, tested (call it whatever you want) version is released - if at all. This project gets developed in spare time and there's no commerical purpose behind it and it's done voluntarily and not by a professional and and and ... so what? Well, as you can see I'm angry and yes, I knowingly do not abide by that unwritten law not to criticize anybody's work here, but I'm displeased, so I take this burden, no problem. According to Ebay I'd give a "neutral" and not the usual canticles. Ah, for those who can't wait to rail against me: of course, I'm consistent and don't continue "using" the packs for now. That's what at least for now saves me more time, money and nerves. This said I erased the last big error source regarding my UDVD which makes it rather stable and finished. So, a big thank you to all of you guys here and your help!! Most of the time it's been worth it.

Hi! I've read all of your replies and sure, you're right, of course. I'm pretty much aware of many facts you've written down. And I want to state it cleary that by no means I did want to blame anybody for anything - this was not my intent. In fact, my problem was and still is just the following: downloading and using the most recent DP I can't be "sure" if it will work without any fatal setup errors, no matter due to what reason they emerge. Maybe this is no more a problem today (I dunno since I haven't tried a new pack yet) but some time earlier I faced many annyoing (fatal setup) errors which cost me really much time getting around them. I by the way don't refer to improper driver integration which merely makes the drivers not being recognized by the system, this wouldn't have been so bad. So the idea arose why not create so called stable builds like it is good maner in software development business?! Stable build as a term just to emphasize the fact that the user can be sure that there won't be any occurences that'll cause setup routine to hang which, of course, mainly concerns integration of mass storage drivers. And stable build not as a term that means newest drivers, features, etc. by any means. For the time being I found a stable build - at least for me, please don't ask me for its version number now. :hehe: Some days ago I tinkered with the idea of updating my DP to a newer version and again found some hints on the board that there are probably errors which will prevent setup to succeed. So I stuck to my old version because I can't afford to loose my system again and spend much time on get it going again. That's how I came to the idea of "stable packs" ... just to let the user know: "Okay, I can use that newer DP version without having to be anxious about fatal errors." No matter what's going to happen, this hasn't been personal criticism, it's just a proposal with respect to my own experience with the DPs.

Hi! Just wondering if there's a chance that you bring out a stable release of your driver packs? I mean a release where you concentrate solely on removing errors like BSODs, missing configuration file lines, etc. instead of implementing new features or new driver versions which anyway only include minor changes most of the time. I'm now using use an old pack version and at least for my hardware it seems to work more or less well. Thanks! But I really hesitate to make use of newer versions because I can read ever and anon of new problems which make a burned UXPCD with your drivers included worthless because setup won't succeed due to those errors. Often the hdd is formated then already which causes really big trouble and time loss to get a working system again with another cd. "Unfortunately" I am reliant on software which works fine right from the start because I don't have the time nor hardware to perform several tests. So maybe there's a chance that you release stable versions from time to time where users can be almost sure things work out fine? That would be great! Of course, these don't have to include the newest drivers, this is of almost no importance in practical use. Maybe this could be just one big zip-file where all needed components are included and one doesn't have to search for them before either. regards

Hi! Thanks a lot for those instructions! And I also want to get rid of the standard QuickTime package and therefore I use the alternative codecs. But what confuses me is your explanation above. If I extract the temporary files there's only that iTunes.msi next to a ISScript8.Msi. So I believe the QuickTime components must reside in the iTunes.msi as well. But how could one get rid of them if this is true? They don't seem to be in a separated file or whatever as your explanations imply.

Erm .... can someone translate this into English and a comprehensible description respectively?? Thanks a lot in advance!

jap, u r supposed 2 be rite

Hi! Well, not sure if this data really can help to solve the problem, also with respect to your previous message. But the PC concerned has got an Abit KT7A-RAID mainboard with HighPoint 360 controller as far as I can remember. Yeah. But I'm not quite sure if the guy in charge of maintaining those packs is in favour of solving this at all.

Here r the (original) HighPoint drivers (v. 2.351) that I use for updating my system and that make stand-by mode etc. available again. Maybe they're useful 4u. Highpoint_HPT370_RAID_v2_351.rar

I again installed Windows with my UXPCD yesterday and now here's what I've figured out. I used method 2 with following updated versions of your packs: Base v5.02.2 and MassStorage v5.05. There were no copy errors during setup routine this time by the way. 1.) Now the HighPoint 3xx controller gets detected well as "hpt3xx" and not as "ahpt3xx" like before. This also increases harddisk spead sensible. Great! 2.) But there's still something funny which I also exactly faced the same way before when applying Ryan's pack. Even though I don't have to put a floppy disk in for my RAID drivers because I use your packs it still displays Microsoft and "UNSUP" respectively as the driver manufacturer in device mamanger and not "HighPoint" what ought to be indicated there after a proper driver installation. At the same time the stand-by as well as the hibernation mode are not available, i.e. greyed-out. :-/ Again this points at problems with driver installation. After I manually install/update the HighPoint RAID drivers in device manager all things work well: right manufacturer info is displayed and stand-by modes are working then, too. This by the way wasn't the case before with your old MassStorage pack. An update didn't help then to make stand-by mode working again. So at least this improved with your last pack update. But again in medias res, see the enclosed screenshots: the first picture of each pair displays the information right after Windows installation with your new packs and the second one shows the same window after I've updated the HighPoint RAID driver (v2.351) manually using device manager. Well, what's your opinion here? I'm not sure about this phenomenon.

@Ctwizzy Thanks a lot for the good questions you've posed! They really helped me a lot, too, since this forum's (informational) structure isn't very user friendly to catch on.

Well, since it worked with Ryan's pack I supposed it must be linked to something you did in your own packs, maybe just a mistake with the hwids. That's just an assumption though it sounds strange that two different drivers compete for the same hardware devices. And btw I didn't blame you, my intention was just to tell you that there's something wrong. I thought you said that you wanna get bug reports. This is one.

Hi! Following things I encounternd while making use of your packs. My conf is: XP SP2 slipstreamed (German), including all serv.packs (till mid of April) tried to include all of your packs using method 2 for testing purposes 1.) aliide.sys problem I searched for the solution on my own and found that just simply adding the following line in txtsetup.sif under section [sourceDisksFiles] solves it perfectly. But you already seem to have gotten to the bottom of it in another thread. aliide.sys = 1,,,,,,3_,4,1,,,1,4 2.) Mass storage (HighPoint 3xx) I have got an ATA HighPoint HPT3xx RAID-Controller. Having your mass storage pack slipstreamed I can avoid putting a floppy disk in, i.e. Windows recognizes the raid controller and can access the hard disks at any time. --> Ok! But odd enough it doesn't seem to use the correct driver files. Using the floppy disk to get the raid drivers installed the controller is recognized as "hpt3xx", but with your pack slipstreamed the device's name is displayed as "ahpt3xx" (mind the initial "a") at the beginning of the text-based windows setup. Though it's working as I've written earlier. But ... later on in Windows after everything got installed (using your mass storage pack) there's neither the stand-by-mode available nor hibernation mode. Using my own floppy driver files this problem doesn't occur. And using Ryan's pack this problem doesn't occur either. So it's likely that there's a driver problem in your packs due to using wrong driver files. The following information is also covered by the enclosed screen shots: After setup is finished device manager displays the HighPoint controller as "HPT370 UDMA/ATA100", but also an "Adaptec RCM device" which I haven't seen ever before. I think this is the connection to the little "a" in text-based windows setup mentioned before: a -> Adaptec. Moreover, the HighPoint driver file information in device mananger indicates that Windows-internal drivers are used according to version and manufacturer data. I can update the HighPoint driver with my floppy disk and afterwards it displays the right data in device manager, i.e. "HighPoint HPT3xx ATA RAID". But even after this update the stand-by as well as the hibernation mode is still inactive what seems to be related with that Adaptec device which obviously causes some incompatabilities I didn't know before.