Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Updated 4UTILS and SYSUTILS

May
12,846
164
4UTILS now contains

Code:
v:\> help @filereadi
@FILEREADI[N,1|2|4|8[X]] = unsigned 1|2|4|8-byte integer from file N; X = hex

And SYSUTILS now contains

Code:
v:\> help @exebits
@EXEBITS[exe|dll|ocx] = 32, 64, or N/A, plus subsystem

v:\> help @exetime
@EXETIME[exe|dll|ocx] = build time
 
My interpretations:

@filereadi returns the signed integer of the specified number of bytes from handle N as a decimal string or a hexadecimal string if qualified by X. In the same manner as @fileread and @filereadb the file pointer is moved the specified number of bytes.

@exebits reports of the characteristic of the function argument: a named file whose extension is one of exe, dll or ocx.

@exetime reports of the nominal build instance of the function argument: a named file whose extension is one of exe, dll or ocx. What build time is I don't know - probably when the linker modified the binary file, but it could be that of the main, the dll main, or some other event.
 
My interpretations:

@filereadi returns the signed integer of the specified number of bytes from handle N as a decimal string or a hexadecimal string if qualified by X. In the same manner as @fileread and @filereadb the file pointer is moved the specified number of bytes.

@exebits reports of the characteristic of the function argument: a named file whose extension is one of exe, dll or ocx.

@exetime reports of the nominal build instance of the function argument: a named file whose extension is one of exe, dll or ocx. What build time is I don't know - probably when the linker modified the binary file, but it could be that of the main, the dll main, or some other event.
1. Yes ... I left out negative numbers because it was hard to imagine knowing that there was a negative integer of a known size at a known location in a file.
2. Yes (I'll change that to "exename|dllname|ocxname" for clarity)
3. (DWORD) TimeDateStamp is a member of the IMAGE_FILE_HEADER structure ... which is a member of the IMAGE_NT_HEADERS structure (commonly called the "PE header"). I suppose the linker puts it there when the program is linked. It's a UNIX-like stamp (seconds since 1/1/70 00:00:00).

Code:
v:\> echo %@exetime[g:\tc16\tcc.exe]
2014-05-07 12:03:19 UTC

v:\> echo %@exebits[g:\tc16\tcc.exe]
32-bit CUI
 
1/ Sorry I failed to notice you stated unsigded. But your qualms are misplaced. Knowing what is where, including signed v. unsigned, and size of integer, is strictly user's responsibility. I either do or do not have a map of the file. I would not worry who knows what. OTOH I would make a flag for signed vs. unsigned for decimal numbers; possibly a choice of S, U or X.

2/ Never saw CUI - nor does Google search found it.
 
1/ Sorry I failed to notice you stated unsigded. But your qualms are misplaced. Knowing what is where, including signed v. unsigned, and size of integer, is strictly user's responsibility. I either do or do not have a map of the file. I would not worry who knows what. OTOH I would make a flag for signed vs. unsigned for decimal numbers; possibly a choice of S, U or X.

2/ Never saw CUI - nor does Google search found it.
It's a Windows term. When you Google, throw in "Windows" or "Subsystem". From the docs for IMAGE_OPTIONAL_HEADER (which is not at all optional) ...

IMAGE_SUBSYSTEM_WINDOWS_CUI
3
Windows character-mode user interface (CUI) subsystem.
 
New version of SYSUTILS doesn't load:

Win XP SP3, TCC 15.01.58

Code:
C:\work> dir      c:\temp\sysutils.*

 Volume in drive C is AUDREY         Serial number is a412:8326
 Directory of  C:\temp\sysutils.*

05-14-2014  22:14             118  sysutils.dat
05-14-2014  22:14         105,472  sysutils.dll
05-14-2014  22:14          10,209  sysutils.txt
           115,799 bytes in 3 files and 0 dirs    122,880 bytes allocated
    31,574,159,360 bytes free

C:\work> plugin /l c:\temp\sysutils
TCC: (Sys) The specified procedure could not be found.
 "c:\temp\sysutils"

(%?=0, %_?=2)
 
New version of SYSUTILS doesn't load:

Win XP SP3, TCC 15.01.58

Code:
plugin /l c:\temp\sysutils
TCC: (Sys) The specified procedure could not be found.
"c:\temp\sysutils"

(%?=0, %_?=2)

Did a previous one work for you? How old was it? I gave up paying particular attention to XP a long time ago. And the differences between the latest and the previous one include nothing that should cause it to fail in XP.
 
Oops! I did change from GetDateFormat to GetDateFormatEx, the latter requiring Vista (ditto for GetTimeFormat[Ex]). Since it is not at all consequential, I backed off on the change and uploaded a fixed one. So download it again.
Sooner or later I'll include a feature that will fail, without work-around, for older OSs. Anticipating that event, be sure to keep a copies of my plugins in a safe place.
 
For me on WinXP all older versions worked, last one dated 2012-12-26@17:53:56. Attempting to load the latest (presumably the DLL loader from the PLUGINS directory) reports TCC: (Sys) The specified procedure could not be found. For now I revert to the older version. 4utils.dll update was successful.
 
The previous version that works for me is dated 02/02/2014. It's version 11 build 6.
I downloaded the new version, and got the same error as before. I've reverted to the 2/2/14 version.
 
Last edited:
Any particular reason why @filereadi is restricted to 1, 2, 4, and 8-byte integers? I have files with 3-byte signed integers.
In principle, one could have 5, 6, or 7-byte integers, too.

I second the earlier request for a flag as to whether to return a signed or an unsigned integer.
 
Only a handful of files have changed since February and I can't find anything in them that shouldn't be in XP. I built it again, from scratch, and uploaded it again. Please try again. Could it be that someone is cacheing internet content on your behalf? The one you get should have this in its DAT file:

sysutils.dll
Size: 105472
CRC: B6F88D05
MD5: 02D292FEF5707FC8F4BBD183E1CECE46
TimeStamp: 2014-05-16 04:03:31

And where the heck are you finding 3 bit integers of any kind?
 
OK, I found another change I made a couple months ago that won't work with XP. I made a quick fix (which meant disabling @MODULE) and built one that has the two new features (but no @MODULE) and should work for you. I'm attaching it in dave.zip. So, Dave, if it works hang on to it, as well as your one from February. I can't continue to make special builds that'll work in XP and I do want to take advantage of features of newer OS's. To be honest, I can't even keep track of the differences. My sincere apology to you and anyone else who may be disappointed.

P.S. I didn't want to leave XP but gave in a couple years ago. That you've made it this long is amazing!
 

Attachments

  • dave.zip
    52.3 KB · Views: 248
Vince,

Thanks for the special build. Unfortunately, this, too, does not work. I'm working on bringing up a new
computer with Windows 7, so I won't need special fixes long term. Also the new features you put into
the current version of SYSUTILS are specifically 64-bit, and I won't need them until I put my Windows 7
system into production, so there's no need to build me any extra versions. I'm happy with SYSUTILS
v11 bld 6 for now.

Yet, for the benefit of the handful(?) of other XP users, I may still report errors on XP.

As for the 3-byte integers, I find them in the datafile of an application that runs on my Palm TX.
The way I decode these now is by repetitive use of FILEREADB one byte at a time.

I experimented and found that %@EVAL[%@FILEREADI[%fh,4] AND 0xFFFFFF] works well,
but leaves the file pointer one byte beyond.

I appreciate the work you've put in to these plugins. Thanks!

Dave C.
 
While I have a Win7-64b available, my primary one is still WinXP32b. I had developed a multitude of code that do not work on anything newer than XP (and cannot be updated even there). Most of the code is unique to analyzing my bank accounts and the like. So I am stuck.
You want to know what's a major reason for medical costs? A million perfectly functional and not amortized XP computers need to be replaced with nothing more capable machines using Win7 (and often less functional=not retrained for new UI). How many doctors, nurses and technicians will use the superceeded UI and make medical mistakes?
You and I have both been after Rex for backward compatibility, and nearly always got it...
As Dave wrote, even the latest version of SYSUTILS.DLL fails on XP. I suppose I just have to grin and bear it to revert to the last working version (I have most of older versions).
Obviously, eventually there will be plug ins requirng Win7, some Win8, some Win8.1, and whatever future versions. It would be nice if these would be in separate DLLs based on what is the prerequisite. New, restricted development in different packages.
 
Dave, please zip the February version of sysutils.dll and post it here.
 
Dave, I found that my computer at work is using the 2/2/14 version of sysutils. When I compare it to the one I built especially for you, I can't find a reason why that special one won't work in XP. I have zipped my copy of the 2/2/14 version and attached it as dave2.zip. Please try it and tell me if it works. Thanks.
 

Attachments

  • dave2.zip
    51.6 KB · Views: 242
FWIW, here's a little BTM that will turn an even number of hex digits (prefixed with "0x") into a signed integer (with a few examples using 3-byte hex numbers).
Code:
v:\> type hex2neg.btm
iff "%@instr[0,2,%1]" NE "0x" .or. %@eval[%@len[%1] %% 2] NE 0 then
  echo need "0x" and an even number of hex digits
  quit
endiff
set /a bytes=(%@len[%1] - 2) / 2
set max=%@eval[2 ** (8 * %bytes)=h]
set num=%@right[-2,%1]

iff %@instr[0,1,%num] GE 8 then
  echo %@eval[%1 - 0x%max]
else
  echo %@eval[%1]
endiff

v:\> hex2neg.btm  0xffffff
-1

v:\> hex2neg.btm  0xfffffe
-2

v:\> hex2neg.btm  0x7fffff
8388607

v:\> hex2neg.btm  0x800000
-8388608
 
Dave, I found that my computer at work is using the 2/2/14 version of sysutils. When I compare it to the one I built especially for you, I can't find a reason why that special one won't work in XP. I have zipped my copy of the 2/2/14 version and attached it as dave2.zip. Please try it and tell me if it works. Thanks.

Dave2.zip fails with the same
Code:
C:\work> plugin /l c:\temp\sysutils
TCC: (Sys) The specified procedure could not be found.
 "c:\temp\sysutils"
.

Do you still want a zip for V11 bld 6?
 
FWIW, here's a little BTM that will turn an even number of hex digits (prefixed with "0x") into a signed integer (with a few examples using 3-byte hex numbers).
Code:
v:\> type hex2neg.btm
iff "%@instr[0,2,%1]" NE "0x" .or. %@eval[%@len[%1] %% 2] NE 0 then
  echo need "0x" and an even number of hex digit
  quit
endiff
set /a bytes=(%@len[%1] - 2) / 2
set max=%@eval[2 ** (8 * %bytes)=h]
set num=%@right[-2,%1]

iff %@instr[0,1,%num] GE 8 then
  echo %@eval[%1 - 0x%max]
else
  echo %@eval[%1]
endiff

v:\> hex2neg.btm  0xffffff
-1

v:\> hex2neg.btm  0xfffffe
-2

v:\> hex2neg.btm  0x7fffff
8388607

v:\> hex2neg.btm  0x800000
-8388608

And here's my .btm file which reads n-byte integers from an open file (using @FILEREADB) for
integers of length 0 through 8 (0-length always has a value of 0, of course).

Code:
::function filegetinteger
@echo off
rem File %TCDIR\filegetinteger.btm, 09-Feb-2012 22:17 EST
rem
rem TC function @FileGetInteger[filehandle,numbytes,signed_p]
rem   filenum must have been opened with @FILEOPEN
rem   Read %numbytes bytes
rem   if %signed_p then get sign from MSB of last byte
rem   Bytes are read in low-to-high significance order
rem   At EOF, the partial result is returned as an UNSIGNED integer
rem   If the first attempted read is at EOF, the usual EOF string is returned
set result=0
set power=0x1
set bytenum=0
set x=0
:next_byte
set bytenum=%@inc[%bytenum]
if %bytenum gt 0%2 goto finish_up
set x=%@filereadb[%1,1]
iff %@index[%x,EOF] eq -1 then
  set result=%@eval[%result + (%power * %x)]
  rem set power=%@eval[%power * 256]
  set power=%power%00
  goto next_byte
 else
  rem EOF has been detected
  set x=0
  if %bytenum gt 1 goto finish_up
  echo **EOF**
  quit
 endiff
::
:finish_up
if %@index[YyTt1,%@left[1,%3n]] ge 0 .and. %x ge 128 set result=%@eval[%result - %power]
echo %result
unset /q RESULT POWER BYTENUM     "%_batchname"
quit
 
Dave:
My downloasding of the various versions of sysutils.zip used TCC V11 or V15 to avoid V16'FTP problems. TCC, when attempting to load it, failed. The 2014-02-02 version from my own archives had no problems.
 
Dave2.zip fails with the same
Code:
C:\work> plugin /l c:\temp\sysutils
TCC: (Sys) The specified procedure could not be found.
"c:\temp\sysutils"
.

Do you still want a zip for V11 bld 6?
I do want a zip of the 2/2/14 version that works (for both of you) so I can try to figure out why MY 2/2/14 one doesn't work for you.
 
BTW, a funny thing. The ZIP file is
2014-02-01@20:12:00 56,376 sysutils.zip

but the members are
2014-02-02@00:22:32 118 sysutils.dat
2014-02-02@00:12:02 104,448 sysutils.dll
2014-02-02@00:22:32 9,948 sysutils.txt
 
Here's the original SYSUTILS.ZIP from February 2014. Only the name is different.

Contents:
2014-02-02 00:22 9,948 67% sysutils.txt
2014-02-02 00:22 118 8% sysutils.dat
2014-02-02 00:12 104,448 51% sysutils.dll
 

Attachments

  • sysutils_20140211.zip
    55.1 KB · Views: 226
OK, Dave and Steve. I think I got one with all the features that will work on XP. It may be the last. I made an "XP" directory in lucky's 4Plugins folder and put it there so it will be immune from the usual update process. Please give it a try. Here's a link. Arrrgh! XenForo keeps putting "http://" in front of my link. In fact, even if I don't make a link, XenForo automatically makes it a link and puts "http://" in front of it. So, only the text below is accurate; following the link will fail.

ftp://lucky.syr.edu/4plugins/xp/sysutils.zip
 
Last edited:
I hope to try soon, after I read the forum. The size address looks OK. I must remember to use any old TCC vrersion, but not the latest.
 

Similar threads

Replies
1
Views
2K
Back
Top