Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


Homes32

Member
  • Content count

    11
  • Donations

    $0.00 
  • Joined

  • Last visited

Community Reputation

1 Neutral

About Homes32

Profile Information

  • OS
    Windows 7 x64
  • Country

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Homes32

    PEBakery

    That's the plan. wimgapi for mount/unmount and wimlib for everything else. If wimlib ever supports mount/unmount on windows then we can look at moving everything over. Only time will tell.
  2. Homes32

    PEBakery

    yeah. every since they went away from the filesystem overlay in v6.0 wimgapi has been nothing but a headache. I use wimlib extract or apply for my needs. With wimlib's superior speed and compression you can unpack and repack your .wim in the time it takes wimgapi to finishing mounting it in the first place.
  3. Homes32

    PEBakery

    lol. I thought the batch quip would get your attention Still think its a good example though. the syntax of wb borrows alot from batch. and its really very limited in what it can do, relying on external applicants to do even the simplest of tasks such as accepting user input (choice.com). I can't BASH it to much (hehehehe) though. I cut my teeth on it in my MSDOS days and one of my favorits back in the day was Bart's MODBOOT, wich actually helped spiral me into the world of boot disks, starting with UBCD, then UBCD4Win, and finally Winbuilder. The .ini file is still by choice for writing and storing configurations. Even with its limitations its still the easy choice for maintaining human readable and configurable settings. Don't get me started on XML, and JSON, isn't much better, unless your goal is to pass chunks of data around. Like the author said, its a big job to redo a scripting language and my main point wasn't to start a big debate on what is good/bad or BASH (hehehe I did it again ) winbuilders scripting language again as much as we all love it.....Rather I just want to make sure the focus is on making things better, not just making a fancy new car with a bigger motor for the same cockroach to drive around it. Naturally you first have to convince the cockroach that he should try the chevy vs the ford, and making the controls similar so he can just crawl in and start driving is a good way to get him to take a test drive. As for the reboot offer? If the author wants, I say go for it. Why not. There are still good people there. There are good people at the Oven as well, however make sure you don't call the "command-set formally known as a .script " something other then the word "plugin" or some equally ridiculous offense or you risk being banned.
  4. Homes32

    PEBakery

    Sounds reasonable. I definetely agree with jaclaz that the old syntax is a weird mess resembling something you might get if Batch/cmd copulated with vb on top of an .ini file. its very inconsistent and hard to read and extend "functions/commands" In the messy cases I would rather see time spent on creating viable replacements to take over where ugly hacks (ie MacroLibray/cmd/etc) has been shimmed in to work around bugs than creating compatibility with such monstrosities. We are talking more project script level here though as opposed to app scripts which generally use simple/basic commands that should be mostly drop in comparable in order to speed adaption.
  5. currently only binary's. no headers/docs/libs. would be easy enough to add though.
  6. did they even release a new ADK? The links on msdn still point to the consumer preview version published in feb.
  7. That's great work Thanks! I have integrated your code, cURL.exe is no longer needed but can be copied next to the tool, to be used. @Chris Thanks for the report, should be fixed now. Hi JFX, Looking good! I updated my post above to include some important fixes for the data stream reading to be more reliable and so the number of bytes read gets reported correctly. previously it was possible to get a finished percentage of over 100%. also added better detection of incorrect range inputs and byte ranges for the 6 Win8 cabs. I noticed that these didn't have the same download GUI as the others so I figured you were downloading them different. this way you can download everything with the same functions/GUI and provide a consistent user experience. (you could also use InetGetSize() to calculate automatically but I have found its not always reliable) Something to consider is you may want to add a switch to use cURL instead of just looking to see if it's in the folder. I say this because in the case of winbuilder projects its possible that if this tool is extracted to %Tools% and cURL.exe exists there for some other process the user may experience unexpected/unwanted results. Excellent work. always a pleasure working with you! Homes32
  8. updated with fancy new progress demo! this is fun!
  9. sorry about that. I forgot to set the number of bytes to read. (default is 8KB) fixed and updated original post. as a nice effect now you should be able to use $aNumberOfBytesToRead[2] and $aNumberOfBytesToRead[1] to calculate download progress! Regards, Homes32
  10. BTW: its possible to do download a byte range in autoit without using cURL working for me. Full code attached. Thanks again! Great idea! Homes32 Edit: modified to fix download limited to first 8KB Edit: modified again to include a crude example of how progress information can be obtained. Edit: yet again. Made the progress example not suck as much! Edit: 5/31/12 - Fixes for reading download stream. GetHTTP.rar
  11. very nice work! congrads on the release!
×