Login to Account Create an Account
Posted 20 August 2012 - 09:14 AM
Because when somebody (like me) is making a current Windows CD, all files are already on the harddisk - just ZIP it and upload it.
And If I read that MS has removed download-pages (I just got a PM with another broken MS-link), a HFSLIP ready-2-go makes just more sense.
My idea is to offer a Windows XP-package with all updates in ENU and DEU (that's what I have ).
Probably users here could also offer packages for other Windows-versions or XP in other laguages.
But I have no idea if MS could see problems when MS-updates are downloadable from other sources. I know that there are update-packages for XP available (not from MS!!) which contain also all MS updates, so it should not be a problem in general.
Or is it just stupid nonsense? Any idea appreciated!
Posted 20 August 2012 - 09:40 AM
Cheers and Regards
Posted 24 August 2012 - 07:53 PM
Posted 26 August 2012 - 03:53 AM
Posted 26 August 2012 - 06:40 AM
I'm thinking of Win 2k/xo/2k3 in several langauges. My idea was that we (the users here) could offer these packages. But when it's a problem to provide the download-links here, how to offer these links? Of course, someone could host these links, but it's not as easy as publish a link to a new package here...
Posted 26 August 2012 - 06:57 AM
I'd also host a list of Win2k links on my website and link to your site in case of the XP packages.
Posted 26 August 2012 - 07:56 AM
And I think it's time to have a "list of usefull links" to your site and bristols site
Posted 27 August 2012 - 01:15 AM
Posted 06 September 2012 - 12:51 PM
How is it going?
My HFSLIP-2-Go package for Win2k is almost ready. Have you got any detailed plan about how to make the packages available? Are you going to have a separate page/section/table on your website?
I prepared 4 packages:
Windows XP DEU for SOURCE without SP3
Windows XP DEU for SOURCE with SP3 already included (to reduce the download-size)
Windows XP ENU for SOURCE without SP3
Windows XP ENU for SOURCE with SP3 already included (to reduce the download-size)
All downloads of my update-list are included! (even these updates which I don't use)
I want to make a separate page because I want to write some words about these downloads, e.g. which updates I don't use.
But It's not ready yet... Im working on it...
Edited by Mim0, 06 September 2012 - 12:52 PM.
Posted 07 September 2012 - 11:47 AM
I tried to unravel the HFSLIP source code once back when my brain was missing only a cylinder or two
HFSLIP had to be written before the days of rollups by tomasz86, wildbills, bristols, etc
We all benefitted!!
But, it had to be written for the general case of all possibilities, for all persons, for all situations, etc.
it seemed an impossible task, so it ended up in x-levels deep of FORs, SORTs, IFs, pipes, and ...
But that predicate, of scripting for unknown numbers of future unknowns is no longer the case
instead of 400 files with unknown names, we now have the case of updateRollup v1 or v2
all with known names and switches
I'm not a programmer so I should probably just keep my stupid mouth shut, but
Let a future TZSLIP2GO be divided into two parts
a core part -- TZSLIP2GO_partA_corefiles_v1.exe
and an options part TZSLIP2GO_partB_optionfiles_v1.exe
asks user to point to a place to setup TZSLIP root dir
use new name for root dir to prevent accidental use by HF
... I suggest TZSLIP, no disrespect to others
Then build the dir-file structure using current HFSLIP rules and habits,
then, load TZSLIP root dir with core files all of known fixitude,
basically tomasz86's current root dir for HF
but with daily rollups, patches, etc moved to partB
examples, w2ksp51, directX, media9, mdac, ...
Henry Ford used to say ...You can have any color car you want, as long as it's black
asks user to point to the TZSLIP root dir
then builds dir-file structure for a new batch file
adding rollups, options, .net frameworks, etc.
TZSLIP2GG.cmd is a new batch written from scratch
no disrespect to the HF gods, but the future is not so unknown anymore
part A core files probably has 80 - 100 files
all are known by now
HF has to assume for every case, with unknowns adinfinitum
part B probably has 80-100 of rollups and option files
each of them is also known, with known switches
Abandon HFSLIP which has evolved into a hairball, now at version J
the new batch doesn't need not be written for every possible circumstance
rollups are actually written to solve the HFSLIP hariball problem
a new simple script would be maybe 300 lines
they could be linear and stupid with no sequencing problems
as new rollups are added, maybe one or two lines in the script need to change
each script included in a partB would already know exactly what's in itself, and in partA
and it would know the right sequences, and integrate switches
A TZSIP2GO would take the frustration out of 2k testing for noobs like me
and that would allow broad testing of rollups working towards SP52
as Henry Ford used to say ...You can have any color car you want, as long as it's black
Edited by Molecule, 07 September 2012 - 11:52 AM.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users