Author Topic: About bldlevel  (Read 965 times)

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Thank You
  • -Given: 398
  • -Receive: 79
  • Posts: 2383
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
About bldlevel
« on: September 05, 2019, 11:14:33 pm »
Hi

I have some questions related to the bldlevel command.

1) Do you know some other tools that allows me to see/extract the bldlevel information from files beside bldlevel.exe?

2) Is there any way to include the bldlevel information to an executable that does not have it? Can it only be done while compiling the binary? or can it be applied to binary where you don't have the source code.

Regards

Martin Iturbide
OS2World NewsMaster
... just share the dream.

Andreas Schnellbacher

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 24
  • Posts: 438
    • View Profile
Re: About bldlevel
« Reply #1 on: September 06, 2019, 12:53:35 am »
1) Do you know some other tools that allows me to see/extract the bldlevel information from files beside bldlevel.exe?
No. Most likely, because the usage is simple.

2) Is there any way to include the bldlevel information to an executable that does not have it? Can it only be done while compiling the binary? or can it be applied to binary where you don't have the source code.
Adding BLDLEVEL information to executables

The buildlevel is added to the .def file. AFAIK that requires a compiler.

The EDM/2 Meta Index is very helpful for developing.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 149
  • Posts: 2148
    • View Profile
Re: About bldlevel
« Reply #2 on: September 06, 2019, 12:59:14 am »
As far as I know, it has to done when compiling the binary. I guess if a binary had a large description, the description could be replaced with a binary editor. Most exe's don't have a description, which is also added in the def file.
Actually, bldlevel does complain about not finding "driver EA's" so perhaps that is a way.

Pete

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 36
  • Posts: 844
    • View Profile
Re: About bldlevel
« Reply #3 on: September 06, 2019, 03:11:11 am »
Hi Martin

If you have a copy of USbcfg installed then you should also have a copy of GETDESC.DLL which USBcfg uses to extract buildlevel information. However, this DLL is built to work with Pascal coding so would probably need a bit of reworking to work with "c" code.

The DLL was put together by Lars, of USB drivers fame, so you could ask him if he could build a "c" version.


Later Edit: The zip file Lars sent me contains source (cpp, def files) and makefile so you could probably modify it yourself. Let me know if you want a copy.


Regards

Pete
« Last Edit: September 06, 2019, 06:36:25 am by Pete »

André Heldoorn

  • Hero Member
  • *****
  • Thank You
  • -Given: 119
  • -Receive: 19
  • Posts: 787
    • View Profile
Re: About bldlevel
« Reply #4 on: September 06, 2019, 07:43:09 am »
2) Is there any way to include the bldlevel information to an executable that does not have it?

HELLO.C:

Code: [Select]
#include <stdio.h>
int main(void)
{
printf("Hello, world!\n");
return 0;
}

TEST.CMD (requires ICC.EXE):

Code: [Select]
/* Not tested */
CALL CharOut 'APPEND.ME',"@#os2world.com:0.00#@##1##Fri Sep 06 07:08:09 2019 secret::::2::@@ One and one and one is tree"||D2C(0)
CALL CharOut 'APPEND.ME'
'@ICC HELLO.C'
'@LXLITE HELLO.EXE'
'@COPY HELLO.EXE /B + APPEND.ME /B Hello2.EXE'
'@CLS'
'@BLDLEVEL.EXE HELLO2.EXE'
'@HELLO2.EXE'
EXIT

If you are allowed to touch the EXE, believe it's important, and perhaps have an undo-script in case the compiled code is broken. Now, or e.g. after using RC.EXE to append an icon to a PM executable later.

André Heldoorn

  • Hero Member
  • *****
  • Thank You
  • -Given: 119
  • -Receive: 19
  • Posts: 787
    • View Profile
Re: About bldlevel
« Reply #5 on: September 06, 2019, 08:10:30 am »
Depending on the goal, maybe almost hidden text can be added to ZIP files (without an executable-shaped prefix) instead.

Code: [Select]
DIR > TEXT
ZIP TEXT1.ZIP TEXT
COPY TEXT /B + TEXT1.ZIP /B TEXT2.ZIP
CLS
UNZIP TEXT2.ZIP

To extract, stop reading when you've found the original header of the ZIP file (if the file TEXT doesn't contain the same characters).

Lars

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 43
  • Posts: 421
    • View Profile
Re: About bldlevel
« Reply #6 on: September 06, 2019, 09:16:19 am »
Hi Martin

If you have a copy of USbcfg installed then you should also have a copy of GETDESC.DLL which USBcfg uses to extract buildlevel information. However, this DLL is built to work with Pascal coding so would probably need a bit of reworking to work with "c" code.

The DLL was put together by Lars, of USB drivers fame, so you could ask him if he could build a "c" version.


Later Edit: The zip file Lars sent me contains source (cpp, def files) and makefile so you could probably modify it yourself. Let me know if you want a copy.


Regards

Pete

Err,  I have to admit that in the end, GETDESC.DLL also uses a direct call to "bldlevel.exe" to extract the description info. The DLL just pipes the output into a memory buffer, extracts the description string and passes it back into the string buffer provided by the caller.

The reason for this: Initially (on my first attempt) I determined that the description would end up (for the compiler and linker toolset that I used) in the resident name table of the DLL (that's a place in the DLL file that serves a special purpose).  I was done and everything was fine. Unfortunately, another compiler and linker toolset would NOT place the description info into the resident name table but "somewhere else" into the file.
In short: there was no common way to determine this info and therefore I used bldlevel.exe which just scans the complete file for the description string template.
« Last Edit: September 06, 2019, 09:30:28 am by Lars »

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 149
  • Posts: 2148
    • View Profile
Re: About bldlevel
« Reply #7 on: September 06, 2019, 04:39:06 pm »
Wonder about FileVerGetVersionStringFromFile() and the corresponding FileVerCreateModuleVersion() and  FileVerParseModuleVersion() which don't seem to be documented. Also seems to be CSFGETVERSIONSTRINGFROMFILE() in filever.dll.
Markexe has the option "SETVERSION      - Write 32 bit Module Version Field" as well. I also notice that exehdr outputs the bldlevel string.

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Thank You
  • -Given: 398
  • -Receive: 79
  • Posts: 2383
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: About bldlevel
« Reply #8 on: September 06, 2019, 06:31:51 pm »
hi.

I noticed that there may be some bldlevel clone.
Code: [Select]
[C:\os2]bldlevel bldlevel.exe
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#IBM:14.082#@ Build level display facility
Vendor:          IBM
Revision:        14.82
File Version:    14.82
Description:     Build level display facility

On OSFree some time ago for my experiments I grabbed their bldlevel.exe.

Code: [Select]
[C:\HOME\DOWNLOADS]bldlevel
Build Level Display Facility Version 1.1
(C) Copyright 2003-2004 by Yuri Prokushev

     Use the BLDLEVEL command to search for a version string in a file.

     SYNTAX:  bldlevel [drive:][path]filename
         or   bldlevel /?
         or   bldlevel

     Where:
       drive           Specifies a drive letter for the path or filename,
                       for example: C:
       path            Specifies a path,
                       for example: \os2\dll\
       filename        Specifies the name for the file.

     /?              Displays this information.
     no parameter    Displays this information.

I guess there is an open source bldlevel clone by Yuri Prokushev, but I don't know exactly where is the source code in the OSfree repo.

Regards
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Gregg Young

  • Jr. Member
  • **
  • Thank You
  • -Given: 1
  • -Receive: 6
  • Posts: 52
    • View Profile
Re: About bldlevel
« Reply #9 on: September 06, 2019, 09:34:28 pm »
As far as I know, it has to done when compiling the binary. I guess if a binary had a large description, the description could be replaced with a binary editor. Most exe's don't have a description, which is also added in the def file.
Actually, bldlevel does complain about not finding "driver EA's" so perhaps that is a way.

There is an EA that looks as if it would do this:
From the OS/2 programing guide
The .VERSION extended attribute (EA) contains the version number of the file format, as shown below.


    My_Application 1.0



The name of this EA consists of the string ".VERSION". The value of this EA contains the file object version number. This attribute can be ASCII or binary. Only the application that created the file object should modify the value of this EA. It can also be used to indicate an application or dynamic link library version number.

Remy

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 12
  • Posts: 192
    • View Profile
Re: About bldlevel
« Reply #10 on: September 07, 2019, 01:10:41 am »
Hi

I have some questions related to the bldlevel command.

1) Do you know some other tools that allows me to see/extract the bldlevel information from files beside bldlevel.exe?

2) Is there any way to include the bldlevel information to an executable that does not have it? Can it only be done while compiling the binary? or can it be applied to binary where you don't have the source code.

Regards

Just use AddToFile.cmd from David Azarewicz
https://88watts.net/software.html

Regards
Rémy

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 149
  • Posts: 2148
    • View Profile
Re: About bldlevel
« Reply #11 on: September 07, 2019, 01:14:29 am »
Just use AddToFile.cmd from David Azarewicz
https://88watts.net/software.html

Regards
Rémy

That's to simplify adding the bldlevel info during building.

Alex Taylor

  • Sr. Member
  • ****
  • Thank You
  • -Given: 10
  • -Receive: 16
  • Posts: 273
    • View Profile
Re: About bldlevel
« Reply #12 on: September 07, 2019, 01:39:43 am »
Veit Kannegieser's RXUNLOCK library has the RxBldLevel() function. 

Interestingly, it occasionally finds BLDLEVEL signatures in executables where IBM's BLDLEVEL doesn't.  I guess it uses a more tolerant search mechanism (TTBOMK it basically does a brute force search for the BLDLEVEL header through the whole file).

In theory, I think the BLDLEVEL signature can be anywhere in the file.  In some cases when using REXX2EXE, I've found simply doing a binary append of a prebuilt BLDLEVEL signature to the EXE after the fact has worked.  e.g.
Code: [Select]
        @rexx2exe blah.cmd blah_.exe /2 /k       
        @copy /b blah_.exe+blah.blv blah.exe
(where blah.blv is a text file containing the pre-formatted BLDLEVEL signature).

OTOH, this technique does not work for some other executable types, like VX-REXX apps.  It probably has something to do with how the executable wrapper works.  (I've never tried this trick with an already-linked object code a.k.a. 'native' EXE.)

walking_x

  • Jr. Member
  • **
  • Thank You
  • -Given: 3
  • -Receive: 6
  • Posts: 97
    • View Profile
Re: About bldlevel
« Reply #13 on: September 14, 2019, 07:35:31 am »
Be careful with various versions, because original bldlevel has a limit on searching string in a file.

Not sure about the exact limit, but looks like only first 500 or 512kb of file is scanned. Signature placed after this position is just "invisible".

Lars

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 43
  • Posts: 421
    • View Profile
Re: About bldlevel
« Reply #14 on: September 14, 2019, 09:16:00 am »
Be careful with various versions, because original bldlevel has a limit on searching string in a file.

Not sure about the exact limit, but looks like only first 500 or 512kb of file is scanned. Signature placed after this position is just "invisible".
...which would explain why IBM linkers place this string into the resident name table ...