Jump to content

Universal Extractor


nitro322

Recommended Posts

StuffIt Expander - Once upon a time, StuffIt Expander used to be freely redistributable on Windows. That changed after v6.0, which is why I include such an old version in UniExtract. I'll check out the new version, but I can't imagine that they would've all of a sudden decided to make it freely redistributable again after all this time.

It appears they have:

sshot14zi5.png

Link to comment
Share on other sites


It appears they have:

Freely available and freely redistributable are two very different things. Think about the various tools and utilities you can download from Microsoft, such as the sysinternals tools (filemon, regmon, etc.). Those are freely available, but absolutely not freely redistributable. I'm pretty sure the same applies here, but like I said, I'll look into it.

Link to comment
Share on other sites

got a bug report: i'm using win98se(german) +usp2 and version 1.4.1, 1.4.2, 1.5 of uniextractor (with and without installer) simply not working... after some detection of type of installer it always stated ' ... seems to be supported but someting went wrong...' ...

this time i find maybe one or teh reason: even the zipversion seems to delete my whole PATH variable!

Unfortunately, this is somewhat of a known issue. AutoIt and Windows 9x seem to have a whole lot of difficulty agreeing on the PATH, so I've been hacking awaay at various workarounds for the last few versions. You can read through this thread for some of my frustrations with this issue (also look for some of drugwash's previous posts - it sounds like he had the same issues).

I'm going to continue to work on that when I have time, but Windows 9x is not officially supported, so this is a "when I have the time" kind of issue.

thanks nitro for further investigating this topic.... i also tried to pindown the problem....

'winset.exe' works... for instance, if start uniextractor with this bat:

start.bat

''winset path2=%path%;c:\uniextractor;c:\uniextractor\bin

uniextractor.exe

winset path=%path2%''

... the path variable is recovered succesful & not destroyed (but uniextractor is also not working.... :/)

Avoid using "start" as a batch file name because it can conflict with START.EXE. The second line of your batch file should be "start /wait uniextractor.exe".

I am able to consistently preserve the PATH variable on Win98SE, regardless of AutoIt error state, by running it from a batch file set to hide its window and output:

univextr.bat:

@SET PATH1=%PATH%

@START /wait Uniextract %1 %2 %3 %4 %5 %6 %7 %8 %9

@WINSET PATH=%PATH1%

@SET PATH1=

Note that the first SET doesn't need WINSET because it's running in the local copy of the environment. The final SET (to erase the temporary variable) would not be necessary if you never run the batch file from within an existing command prompt, since it will be deleted when the local environment scope ends anyway. The %1...%9 are only there as a kludge to handle files dropped on the batch, and will cause dropped files to extract with an 8.3 filename.

If you create a shortcut to the batch file, you can edit the shortcut properties to make the batch window open as a minimised button on the taskbar.

Unfortunately, this system requires me launching UniExtract via the batch file (or a shortcut to it), and then dropping a file on the UniExtract window to work properly. I haven't attempted to modify UniExtract or the necessary registry entries to fix the right-click menu options. If UniExtract is run any way other than from the batch file, it will of course still clobber the PATH variable. This setup also does not address the problem of UniExtract announcing the following error after each run, despite successful extraction:

-AutoIt Error

-

-Line 0 (File "C:\Program Files\Universal Extractor\UniExtract.exe"):

-

-if @OSType == "WIN32_WINDOWS" AND $oldpath <> " then runwait($cmd & filegetshortname(@scriptdir & '\bin\winset.exe') & ' path=' & $oldpath,

-@windowsdir, @SW_HIDE)

-

-Error: Unable to execute the external program.

-

-A device attached to the system is not functioning.

-

-{ OK }

It's worth noting, of course, that this error dialogue refers of course to AutoIt code that mentions winset.exe, not to the batch file's call to WINSET. This error dialogue occurs on 98SE regardless of whether the batch file is used or not.

I am using Universal Extractor 1.5 on on Windows 98SE v. 4.10.2222 A with Unofficial Windows98 SE Service Pack 2.1a

Reference: http://www.ericphelps.com/batch/samples/samples.htm

Link to comment
Share on other sites

Please note that this project has its own subforum now. It is here. Feel free to strart creating new topics to make communication easier.

Sweet. Now I know I've truly hit the big time. :-)

I've never been an admin of this particular bulletin board system. Is there some reference guide or something available on common admin tasks, such as setting a thread sticky, locking threads, etc.?

I am able to consistently preserve the PATH variable on Win98SE, regardless of AutoIt error state, by running it from a batch file set to hide its window and output:

<SNIP>

IIsi 50MHz, thanks for the detailed post. Hopefully it help some others that are still using Windows 9x. However, I should let you know that as of 1.6 Windows 9x moves from "unsupported" to "won't work" status. Due to some changes in AutoIt, Universal Extractor will literally fail to run going forward. Version 1.5 will continue to be around, of course, but that's the last release that will work, well, semi-work, under 9x.

Additional details can be found by searching this thread.

Link to comment
Share on other sites

I've never been an admin of this particular bulletin board system. Is there some reference guide or something available on common admin tasks, such as setting a thread sticky, locking threads, etc.?

Never mind, got it figured out now. :-)

Link to comment
Share on other sites

(war59312 @ Feb 20 2008, 02:35 PM) *

Unable to extract: http://intype.info/forums/discussion/421/i...finally/#Item_0

This works fine in the dev version. It's probably an Inno Setup issue. Try downloading the test 0.20 version of innounp and replacing the innounp.exe binary in your existing install then extracting again.

Excellent, thanks! Indeed works fine now.

Link to comment
Share on other sites

When can we expect a new version?

I hate to give such a cliché answer, but "when it's done." For the most part, it is done. I just haven't had time to put together the final package, test, and release. I'm hoping to get to it sooner rather than later, though.

Link to comment
Share on other sites

Beginning with version 1.6, UniExtract will not work under Win 9x. Period. This is due to changes in recent versions of AutoIt.

Puzzled, AutoIt forum is only discussing discontinuing 9x and NT support. What tricky stuff in Universal Extractor is pushing the boundary?

Anyway, would it be possible to leave those of us who will be left behind with some hints of where the problems have been found on Win9x?

[Why do I want to continue to use Win9x? Its the usual conflict between improved OS and worsening licence conditions!]

Jeff

Link to comment
Share on other sites

[*]legally possible - this precludes some filetypes, such as InstallShield v12 installers or StuffIt .sitx archives; while I can code support for them, I cannot legally redistribute the necessary utilities to extract them

There is a way forward. You may not be able to redistribute certain free unpackers, but the end-user can legitimately obtain such unpackers and add them to the Univeral Extractor\bin\ directory. Universal Extractor could detect the presence of these user-supplied unpackers, and then offer the appropriate upgraded functionality. The installer for Universal Extractor could leave behind a text file offering instructions on how to obtain the optional extras for the \bin\ directory.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...