Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

Cannot get the latest TCMD FileInfo plugin to work on Win9x

- - - - -

  • Please log in to reply
20 replies to this topic

#1
Comos

Comos

    Junior

  • Member
  • Pip
  • 90 posts
  • Joined 03-February 09
  • OS:98SE
  • Country: Country Flag

Hi All,

 

no sure how many of you are using the FileInfo plugin for Total Commander (http://www.ghisler.c...gins.htm#lister), but the latest version somehow I cannot get to work on W9x.

In the new version they mention:

 

Installation
-------------
4 versions are included in this zipped file
- wlx_fileinfo32 and wlx_fileinfo64 are statically linked to MFC, size is larger but no DLL is needed
- wlx_fileinfo32_DL and wlx_fileinfo64_DL are dynamically linked to MFC, size is half the weight but
3 DLLs from MFC9.0 are needed (MSVCP90.dll, MFC90.dll, MSVCR90.dll)
x32 and x64 plugin can be installed in the same directory

Use the plugin auto-install interface, ie just open the zip file in TC
Try to install first the DL variant of this plugin, if TC display an error message then you are missing MFC9 DLL so install the statically linked version of this plugin

OR if you know what you are doing, you can install it manually :
Copy "fileinfo.wlx" in your plugin directory
and add these two lines to your wincmd.ini (in 5.50 and above)
....or use the Lister plugin interface (in 5.51)

 

I tried the version with statically linked to MFC and also the version with dynamically linked to MFC, but in both cases the same error,that the required DLL's are missingn in the system.

The needed MFC files I have in the system.

 

Any idea if there is a way to get it to work?

 

 




How to remove advertisement from MSFN

#2
GrofLuigi

GrofLuigi

    GroupPolicy Tattoo Artist

  • Member
  • PipPipPipPipPipPip
  • 1,356 posts
  • Joined 21-April 05
  • OS:none specified
  • Country: Country Flag

If it's any help, this is 64bit version seeing 32bit version:

 

vHBVIHF.png

 

It works on Win7 and XP, but the 32-bit version sometimes exits silently. I don't have win 9x.

 

Let me know if I can do anything to help you with testing or something.

 

GL

 



#3
jumper

jumper

    2015 All-American Masters HJ'er

  • Member
  • PipPipPipPip
  • 541 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag
> Any idea if there is a way to get it to work?

Yes. What is the exact text of the error message?
Design feedback requested:
KernelEx 4.5.2015
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
Future projects: Kexter - IP40+Ktree+Kexstubs

#4
Comos

Comos

    Junior

  • Member
  • Pip
  • 90 posts
  • Joined 03-February 09
  • OS:98SE
  • Country: Country Flag

> Any idea if there is a way to get it to work?

Yes. What is the exact text of the error message?

Missing DLL's not found in the system.This only message appear during the plugin installation.Even if install it manually,the plugin itself does not work without any error message.



#5
jumper

jumper

    2015 All-American Masters HJ'er

  • Member
  • PipPipPipPip
  • 541 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag
What is the exact text of the error message? Please quote it in full. We need to know the name(s) of the missing DLL(s).
Design feedback requested:
KernelEx 4.5.2015
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
Future projects: Kexter - IP40+Ktree+Kexstubs

#6
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,296 posts
  • Joined 21-June 06
  • OS:98SE
  • Country: Country Flag

The screenshot in post #2 gives the hint: missing API in kernel32.dll. A simple check in the Imports/Exports tab selecting kernel32.dll will reveal the missing API: GetFileSizeEx().

 

Unfortunately, the file cannot be hexed to call GetFileSize() instead, because the result is returned in a different manner. It would require more changes in the source code, which Fran­çois Gannier - the author - did not release publicly.

 

Latest version of FileInfo that works in 98SE is 2.0.10.0 released november 2007.



#7
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,133 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag
It wouldn't be hard to add this function.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#8
Comos

Comos

    Junior

  • Member
  • Pip
  • 90 posts
  • Joined 03-February 09
  • OS:98SE
  • Country: Country Flag

What is the exact text of the error message? Please quote it in full. We need to know the name(s) of the missing DLL(s).

 

The message that is prompted during the plugin installation is shown in czech language and the text is what I wrote before.It doesn't show any specific DLL or missing import/export function.That's why I first dig out the readme and made the test again with MFC files in the system,but again the same error message.



#9
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,296 posts
  • Joined 21-June 06
  • OS:98SE
  • Country: Country Flag

It wouldn't be hard to add this function.

Probably. Just needs a safety check for results that overcome the max FAT32 size that could be read through network from a NTFS partition. I'm not sure how the plug-in, OS, etc would react when such large result is returned, under Win9x.

 

Is there any more activity in the KernelEx department? Haven't seen any update at Leyok's repository in quite some time. Is there any other attempt known?



#10
jaclaz

jaclaz

    The Finder

  • Developer
  • 15,190 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

A few good questions would be IMHO:

  1. WHICH added features/betterings does the current fileinfo 2.21 when compared to the 2.0.10.0 that does work in Win9x?
  2. Are this added features/betterings useful on a 9.x machine?
  3. Is there among the above a particular added feature that represents a "cannot live without" item? 

jaclaz



#11
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,296 posts
  • Joined 21-June 06
  • OS:98SE
  • Country: Country Flag

According to author's page, at least the few crash conditions fixed in v2.20 would entitle a user to update. Also v2.21 adds a couple useful features and a few more fixes.

 

Dunno how vital all of these new features are, but for the occasional developer or advanced user they would sure be of help at times. As for the crashes, they sure are annoying and anyone using FileInfo often (and I, for one, do) would gladly do without.

 

A much bigger question is "would there be any other hidden dependencies that could surface after adding GetFileSizeEx() to KernelEx"?



#12
jaclaz

jaclaz

    The Finder

  • Developer
  • 15,190 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

A much bigger question is "would there be any other hidden dependencies that could surface after adding GetFileSizeEx() to KernelEx"?

Well one can always trace the app with (say) dependency walker under a OS that actually has that GetFileSizeEx() and check the list of used functions.

 

About the features, of course it is assumed that a later version (with some exceptions, like a number of MS Windows Operating Systems ;)) will offer "better" or more  "features", I was only trying to (indirectly) state how it is not like for 4 (four) years, i.e.  since late 2007 up to late 2011 the "occasional developer or advanced user" had been prevented from "occasionally develop" :w00t: or "advancedly use" :unsure: anything because of the crashes :no:.

 

If you prefer the OP - which BTW realized in 2013 how the "latest" versions (since almost 2 years) are not compatible with Win9x - may well risk :ph34r: using the old version, bearing with a few, rare, crashes without a substantial worsening of his overall computing experience, until someone - possibly because of a more "serious" *need*, finds the time (and way) to add that fuinction to KernelEx.

 

jaclaz



#13
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,296 posts
  • Joined 21-June 06
  • OS:98SE
  • Country: Country Flag

FileInfo itself shows all file dependencies and all APIs used by the target file. So it can be used to reveal any missing files/APIs (as shown above). However, sometimes -as is the case with drivers and possibly other files - certain dependencies are well hidden inside the code and will only show up at run time (wdmcheck may help on occasions). That's what I meant with my final question. If no such hidden dependencies exist, then enhancing KernelEx with GetFileSizeEx() would at least theoretically fix it.

 

There is another problem, that FileInfo 2.2x versions only run on Total Commander 8.x (as the author mentioned in the TC forums). I still use one of the earlier 7.x versions, for various reasons. And recently, when I tried to update a bunch of plug-ins, I sadly found out that most of them wouldn't support Win9x, so I had to revert to older versions. For that reason (among others) I keep my current version of TC, just to make sure old plug-ins work correctly. And for the same reason I stopped checking for updates long time ago, that's why I didn't know about the new 2.2x versions (which may as well be the case with the original poster).

 

I don't know if you use TC or how often, but I can honestly say - and please don't take me as an advertiser - that I could never use a Windows machine without TC and its plug-ins. I've got used to it since 1999 or so and it immediately became my most reliable and useful tool. For people like me, switching to something else can be (almost) impossible. I'm speaking from the heart here.



#14
jaclaz

jaclaz

    The Finder

  • Developer
  • 15,190 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

 

I don't know if you use TC or how often, but I can honestly say - and please don't take me as an advertiser - that I could never use a Windows machine without TC and its plug-ins. I've got used to it since 1999 or so and it immediately became my most reliable and useful tool. For people like me, switching to something else can be (almost) impossible. I'm speaking from the heart here.

Sure, I never used TC and I do not  personally think I will ever miss that, but you just confirmed what I was trying to say, you "survived" alright using the "old" version.

 

About dependencies, of course there are "static dependencies" and "runtime dependencies", that's why I suggested to trace  the thingy with DW on a OS that fulfilled that dependency (if you prefer an OS on which that plugin does work aòright) to get the list of *all* dependencies.

 

jaclaz



#15
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,296 posts
  • Joined 21-June 06
  • OS:98SE
  • Country: Country Flag

Vivere e sovvravivere non sono la stessa cosa. ;)

 

I know what DW can do and I know it can miss some things unless the target is put to work in all possible modes. There may also be different kinds of targets (such as scrambled UPX-ed executables, for example) that need to be checked, to make sure every possible dependencies have been called at some point.

 

But I don't have a TC8 installation on a supported OS and most likely won't have one anytime soon, so maybe someone else who does could perform the required tests and share the results. Or we could continue surviving...



#16
jaclaz

jaclaz

    The Finder

  • Developer
  • 15,190 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Vivere e sovvravivere non sono la stessa cosa. ;)

But - just like getting old - the alternative is worse ;) :ph34r:
 
 

Old age isn't so bad when you consider the alternative.


:lol:

jaclaz

#17
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,296 posts
  • Joined 21-June 06
  • OS:98SE
  • Country: Country Flag

To be honest, I wouldn't be so sure. I'd rather die before my pants get brown in the rear too often. :whistle:



#18
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,133 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag


It wouldn't be hard to add this function.

Probably. Just needs a safety check for results that overcome the max FAT32 size that could be read through network from a NTFS partition. I'm not sure how the plug-in, OS, etc would react when such large result is returned, under Win9x.
 
Is there any more activity in the KernelEx department? Haven't seen any update at Leyok's repository in quite some time. Is there any other attempt known?

Reading a File Size under Windows 9x from a NTFS Partition through a Network shows the true size, but there is no way to access more than 4GiB even with my Large File Emulator to receive the data.

I would assume that any program that uses GetFileSizeEx would be able to deal with reported sizes above 4GiB, although they may not realize that they cannot be fully accessed.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#19
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,296 posts
  • Joined 21-June 06
  • OS:98SE
  • Country: Country Flag

In this particular case (the FileInfo TC plug-in), only the file headers are being retrieved from the actual file, not the entire file, so there may not be any problem[1]. Although the plug-in has the ability to disassemble the analyzed file (if the corresponding option is enabled in its .ini file), hopefully nobody would attempt to do that on a 4GB+ file. I have no idea if there is any hardcoded filesize limit for the Disassemble option in this plug-in.

 

Now, if we consider the implementation of GetFileSizeEx() in KernelEx, obviously other applications may use it and there's a chance they may actually try to perform operations on those files (copy/move/edit). How could we best handle the situation, when files larger than 4GB are being accessed over the network: should KernelEx's GetFileSizeEx() return an error, should it return the full size or should it return the maximum allowed FAT32 size, thus fragmenting the file? I suppose the latter - although possible - would be unfair and possibly dangerous. But the others would also produce an error in the application and it would all depend on how errors are handled by each application. So probably the best solution would be to return the full size and let the application deal with the impossibility of handling the file; if the value is for display only, then it better be accurate.

 

 

1. There may be problems with setting/moving/getting file pointer when reading from the end of the file though.



#20
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,133 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag

In this particular case (the FileInfo TC plug-in), only the file headers are being retrieved from the actual file, not the entire file, so there may not be any problem[1]. Although the plug-in has the ability to disassemble the analyzed file (if the corresponding option is enabled in its .ini file), hopefully nobody would attempt to do that on a 4GB+ file. I have no idea if there is any hardcoded filesize limit for the Disassemble option in this plug-in.
 
Now, if we consider the implementation of GetFileSizeEx() in KernelEx, obviously other applications may use it and there's a chance they may actually try to perform operations on those files (copy/move/edit). How could we best handle the situation, when files larger than 4GB are being accessed over the network: should KernelEx's GetFileSizeEx() return an error, should it return the full size or should it return the maximum allowed FAT32 size, thus fragmenting the file? I suppose the latter - although possible - would be unfair and possibly dangerous. But the others would also produce an error in the application and it would all depend on how errors are handled by each application. So probably the best solution would be to return the full size and let the application deal with the impossibility of handling the file; if the value is for display only, then it better be accurate.
 
 
1. There may be problems with setting/moving/getting file pointer when reading from the end of the file though.

GetFileSize already returns the full size so GetFileSizeEx should also.
If I implement it with DLLHOOK, I would pass the results through unmodified.
You cannot get, set, or move a File pointer beyond 4GiB-1 from Windows 9x through a Network.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#21
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,296 posts
  • Joined 21-June 06
  • OS:98SE
  • Country: Country Flag

Just as I thought. Thank you.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users