Glenn9999

How come the LIB is roughly the same size as the DLL? All the other LIB files I've found from Microsoft are functional code libraries linked INTO the EXE (using the .H file as a guide) and not simple interfaces. Why would that case be any different. Actually that brings up the other major problem. Microsoft would disagree with that assessment, especially considering that they have been suing other companies that have used and adapted FAT32 for their own purposes (the phrase "vigrously defend" definitely is true). Such a project would have a lawsuit on it so fast from Microsoft that the participants heads would spin for days.

The headache part for me is deciphering that writing. Other than that, for a simple letter substitution (which is what it would about have to be for someone to write that without the aid of computing machinery), I'm surprised that it hasn't been cracked. Worse come to worse, there isn't that much text there that wouldn't eliminate a brute force solution (substitute letters, write to text, then look at text to see if its intelligible). In a way, though, if they're going to ask the public this it would be nice to know what they HAVE tried.

And actually impossible because Microsoft isn't open sourcing the win9x source, and therefore no one generally knows how things are linked in all the code or the programs. So all would need reviewed. And you'd still break programs because some programs link the libraries into their program (e.g. Kernel32.lib) and don't call the DLLs.

Put the file in a central location you can remember (i.e. this is the real file) and then create hard links for the other spots. either mklink (Vista and above) or fsutil will be useful to look into for this purpose.

Actually this is part of the DVD spec. The files are 1GB a piece, maximum, and are split up into different sections if there is more than one movie. There is nothing special regarding these files from a file allocation perspective. They are individual files with varying sizes and not part of one cohesive unit. The fact still remains no matter how much people want to dance around it. FAT32 does not support > 4GB and neither does 98.

All this kind of looks wierd for a forum like this and I almost passed it up for spam...anyhow... Actually it depends on how it is done. You do get something like this as a woman by weight lifting: But you get that result by using heavy weights and stressing the muscles. Small amounts of weight for multiple reps will tone the muscles and women generally do that if they don't want to look like the picture (and most don't). It helps for appearance since unfit muscles can sag and droop especially in that area. If you want defined abdominals, you got to work them. But it won't remove fat around the belly.

For those who are interested, I did an update of the file downloader I posted earlier. Posted below is version 0.06 beta. Changes from 0.05 beta ---------------------------- 1) Moved the Windows Update Agent version listing to the About & documentation menu. 2) Added more detailed data including URLs to the data list function. 3) Added Security Bulletin to the report data and detail data (For example KB2483614 is security bulletin MS11-017). 4) Gave the project the unofficial name of BatchPatcher Downloader, for lack of a better name. Several places now reflect this. An icon will be generated soon as well as a name change of the executable. 5) Added initial functionality of Bookmarks or URL downloads accessible through the menu. These are read from the file GETNEWSTUFF.INI, which a sample should be included and the format obvious. Changes within the program will come. In addition, the WSUS Offline Scanner download was moved to the BookMarks section.

Some interesting/complex things and I'll do my best to respond to some of them. Generally NTFS doesn't have the 4GB size limitation, but this has to do with what the OS supports. While NT4/NTFS can indeed support >4GB and has the drivers/libraries to support it properly (actually it's a kludge, but that's another topic), win98 wouldn't, so it would cause a problem. The server won't generate any errors because it doesn't know anything is up ("you copied me 4GB. Great!"), but the 98 file/network drivers don't know anything is up either (remember they were written at a time when a 4GB file was thought an absurdity). Yes. That's how files work and have so since the beginning of time. The point where you are reading/writing a file is denoted by a file pointer. It can't be eliminated. Network protocols have nothing to do with file transfer. All they involve is passing data across a network connection and that is all the device knows. The network device knows nothing of file systems and vice versa. TCP/IP is a network protocol which just passes data. Now NetBEUI (NetBIOS) is a complete different thing - it allows organization and identification of the machines. In other words, it enables the machines to hook up and identify one another and identifies routing information. Now on top of that, there is file and printer sharing protocols, which is what you are confusing the network protocols with. The common one that works with your 98 is Samba. This is what has to bridge between the disk and data devices. All of this has been described in a really simplistic and not exactly accurate way, since there is much to study in networking theory regarding this topic (Google "OSI model" or "OSI 7 layer model" if you want to know more, I took a whole college class on this once). Point is, TCP/IP and NetBeui have nothing to do with file pointers. Fifth byte makes it > 32-bit. 32 bits are 4 bytes. As was stated many times in your threads as well as the thread linked to, there is no way to change this for Windows 98 outside of rewriting the whole operating system in every place that it accesses files to use 64-bit pointers (the next step) as well as making a FAT64 file system for hard disks. You really can't kludge data storage. As you may guess, that is a huge task. While it could be done, that would require Microsoft open-sourcing 98 to even make it fruitful and that will never happen. The file system itself does not allow storage of data amounts > 4GB. This goes into the way disks work - all the hardware knows is clusters and the file system is what makes sense of it for the OS. A file system really is a way to track what data are stored on disk and where. The problem is you can't "tolerate an incorrect file-size" in the allocation table, because it will result in data corruption and loss when the data are accessed. A file system is something you really don't want to kludge, for a number of reasons. Again because the file system doesn't support values greater than 4GB. As has been stated many times, Microsoft's answer has been NTFS so there won't be a FAT64 on their OSes. And they only created exFAT because they realized NTFS thrashes flash drives. You can't make anything work on something that is impossible to make work.

True, what the OP requests could be done, the issue really involves whether it's worth doing for such a niche request. As far as we know, there may be a dozen people that would actually use such functionality. Although, such functionality would be questionable in and of itself. Indeed. If you did code a special UNRAR to split files on decompression (instead of compression), you'd still have the problem of reading the file(s) properly. Really probably the best solution if this person plans to stick with 98 is go to a friends place, extract the files and then process the movie into two sections. Of course, that solution depends on how frequently the OP plans on trying 4GB files on FAT32.

In other words, I want to store a file > 4 GB on my FAT32 partition which can only handle 32-bit file sizes using Windows 98, which can only handle 32-bit file sizes and addresses. How do I do this? Short answer: Impossible. Longer answer: Microsoft has an exFAT file system which they have to support flash drives. But only supports as far back as XP. You can look at this thread if you don't believe me - as well you can find an exFat reader someone attempted. It may or may not read your file. Good luck. You will need it. MGDX also posted something here which might help. But again don't get your hopes up.

RAR always has done this even in the DOS days - I remember using it to create 1.44MB files on hard disk to later copy to floppy. Your issue is more with the 4GB boundary part. This would have to do with the storage structures and values used. Most software implemented today likely use LongWords to store numerical data, which have a maximum of 4294967295. As you might be able to see this number represents in the number of bytes (roughly) 4GB. Without a doubt, most probably don't see a need to support that high of a value (or larger) in their software, so it is highly unlikely you will find something that can. This is especially true, since there would be backward compatibility issues in supporting this. You might detail what you are looking to do (it seems like a 2 part video file)? Why not just split the video itself and save it to two disks (this is what most other situations of this type have done)?

http://filehippo.com/download_silverlight/ will lead to one.

Fasterfox is worth looking at, too.

There's really nothing new under the sun. I remember the older mainframe workers talking how the mainframes had features 20 years ago that they tout today in PCs as the great big thing. And they were right. Anyway...that IBM keyboard for the win. Still best keyboard I ever had. Worst part of keyboard selection is whether they work well to type or play games. Some I've had are better and some are worse, but the current one I have has to be the worst one ever for both. Cotton keys, key jamming abound. Hardly can type too fast because I have to keep checking my work for keys not registering. Not to mention the two games I have now I can't play because the key combinations the game requires result in key jamming on the keyboard (for example, numeric 10-key pad and the arrow keys). That IBM keyboard was designed well and worked very well.

For those who are interested, I did an update of the file downloader I posted earlier. Posted below is version 0.05 beta. Changes from 0.04 beta ---------------------------- 1) Finished out the Special Downloads Section. Windows Update Agent now downloads according to the proscribed Microsoft manner and should always produce the latest version of the updater. 2) You can get the currently installed Windows Update Agent version in the Help submenu. 3) Per suggestion, now the progress bar moves while the program retrieves the Windows Update List. 4) Cleaned up a number of things.

As Microsoft's plans of forced obsolescence regarding Windows XP pick up steam, having XP member projects would almost have to be a necessity. Especially a project similar to KernelEx. One has already been started named Alky for Applications, but hasn't been developed much. I'm sure if there is any desire to adopt IE9 on XP, such a project will be forced to completion, since the demand and possibility got mentioned. It would require as much adamant advocation as those in the 9X group, but I'm sure there would be enough.

I tried looking at Diamond EXE and the 95 cabs. Everything either generated by Diamond.EXE or on the 95 disk returns MSZip on the software I'm looking at these files with, so it seems that answers the question.

That link is more of a utility standpoint. Anyhow, there isn't necessarily anything discounting that Microsoft maybe made an error, but it's probably more likely I'm misunderstanding something? (Oddly enough when I search now, this thread comes up as most relevant) if I go into FCI.H #define tcompTYPE_QUANTUM 0x0002 // Quantum #define tcompMASK_QUANTUM_LEVEL 0x00F0 // Mask for Quantum Compression Level #define tcompQUANTUM_LEVEL_LO 0x0010 // Lowest Quantum Level (1) #define tcompQUANTUM_LEVEL_HI 0x0070 // Highest Quantum Level (7) #define tcompSHIFT_QUANTUM_LEVEL 4 // Amount to shift over to get int #define tcompMASK_QUANTUM_MEM 0x1F00 // Mask for Quantum Compression Memory #define tcompQUANTUM_MEM_LO 0x0A00 // Lowest Quantum Memory (10) #define tcompQUANTUM_MEM_HI 0x1500 // Highest Quantum Memory (21) #define tcompSHIFT_QUANTUM_MEM 8 // Amount to shift over to get int #define TCOMPfromTypeLevelMemory(t,l,m) \ (((m) << tcompSHIFT_QUANTUM_MEM ) | \ ((l) << tcompSHIFT_QUANTUM_LEVEL) | \ ( t )) As I understand all I need to do is plug numbers into the macro at the last part and I'll get what I need. So let's say, I go for quantum with the highest level and memory. I get 0x1572, which seems to be what I need to have. I tried to search too and found no indication that Microsoft ever pulled Quantum. So what am I missing here?

I've been trying to make CAB files, and got all the other compression types working, but haven't been able to get Quantum working in any fashion (it returns an "unknown compression type" error). I double & triple checked what I was doing with some other things, and it seems I'm specifying the settings right. So I was wondering, did Microsoft pull Quantum support out of their CAB software, or is there something I'm not seeing?

Now for a serious answer. Yes, writable optical media wears out. If you Google you'll find out that it's not plastic, but a malleable dye (varies based on brand and kind) that the laser on your drive can etch without much problem. This is what degrades. The estimate is 5-10 years for most brands in ideal conditions, though some of the more poorly made brands can go much sooner. Also, they can go in much shorter time (a couple of weeks) if conditions are less than ideal. Using RW disks moves this estimate downward. Personally I give most disks a maximum of a year or two. Given this problem (which I've run into on some data with particularly), I tend to burn a file of MD5 hashes of the other files on the disk to that disk so they can be checked if suspicion of corruption arises.

Thanks for the tip. I had a look at the program, it works well. I like the unattended/automate functionality of it, and was planning on doing that with what I posted (as Batch Patcher is). I wasn't previously aware of it, so it'll be a good reference point. The other program packages I was aware of have numerous problems and drawbacks for my purposes, so part of making things for my personal use is addressing those (along with learning about stuff, I pretty well got the WUAPI functionality worked out). As any hobbyist project I do, I almost always share if I think someone else has interest, and this likely does. As for functionality, there is one thing I have yet to figure out from using Windows Update directly (or the offine scanner file) and will likely try to figure that out before I call my WUAPI code done: How to find out what patches are deprecated by newer ones. I'm sure that can be figured out when the time comes. I gathered in research that CAB files are used by the Windows Update Site and PSF files are used by WSUS. I know about the WU site, but I don't know enough about WSUS to know whether downloading those files separately would be an interesting option or not.

Definitely going on the list. Microsoft doesn't provide a progress indicator in Windows Update (i.e. 25% complete) for search operations. I'll probably just move the progress bar on the wait cycle. Personally I know it's searching when the controls are disabled, but good to do it Meant to get documentation in the text, but didn't. The documentation is in Help/About, though. Probably can make a CHM if it gets complex enough. 1) It queries Windows Update (like the site and automatic updates does) and locates the updates listed there. But instead of doing the normal Windows Update install thing (which uses the CAB links generally), it downloads the URLs indicated there to disk as the user indicates. 2) Same as the Batch Patcher thing. As long as you don't mess with the EXE itself, I don't care where or how you use it. But as the docs say, no guarantees, etc. Since it's a work in progress at the moment (especially since I don't know if Vista or 7 will choke on it yet), I'd rather not have large scale distribution, at least not until it's completed. This program basically has the same intention and reason as Batch Patcher does for me. A portable way to perform small scale automation of the installation of patches with a minimum of trouble. Part of the reason I put it here at this point is so I can get good constructive suggestions like written above. 3) At this point, source is kind of pointless since I've been working on it for a few months and changing a number of things. But probably eventually once I'm sure everything is reasonably stable I can share the whole WUAPI library code I have.

Current test version if anyone is interested.

This is in reference to the Windows Update Automatic Update client. I would think it might help (in not reinstalling) to download the Windows Update Agent appropriate to what you are working with and run it with /WUFORCE - this would replace the files.

Actually there's no such thing. How would something know that silence denotes the end of a song and not a pause within the song? Or how would something know that there wasn't ever meant to be silence (like a live thing). In having done this with numerous tapes, the previous poster's suggestion is what you want - you want something that will capture to WAV. In addition to those suggestions, I'll add Cooledit to the mix if you can still find a copy of it. Works relatively well (much better than Audacity, IMO). Besides that, you don't want anything automated because you'll want to be able to monitor the input from the tape deck into the computer so you don't overload the sound card on input (got to have it good sounding), isolate and reduce any audible clicks or pops, and be able to control normalization of the recording in addition to splitting up the recording. But be prepared to know that the sound quality won't be the same as if you ripped it from CD. That's just how the tapes are (about 96Kbps MP3 equivalent if I remember right). The best thing to do (again experience) after you check the sound level is capture each side of the tape to WAV, post-process using your editor and then convert the pieces to MP3 and then ID3 tag it if desired (there's software to do that). This shouldn't be a concern with modern systems, but you'll want at least 3-5GB of hard drive space free while you do this (per tape). But you aren't going to get out of doing the work.