Versionshistoria WinHex

<<Tillbaka

Förändringar v17.7 -> v17.8

• http://www.x-ways.net/winhex/mailings/index.html

Förändringar v16.9 -> v17.0

• Network Dongles
• Ability to unlock X-Ways Forensics 17.0 and later (also v16.9 SR-4 and v16.8 SR-10) with network dongles. Network dongles are available now as a substitute for regular dongles. A single network dongle can represent x licenses and substitute x regular dongles and allow the users to run X-Ways Forensics on x machines on the same network at the same time. The network dongle is attached to any of the computers on the network and made available to the clients by a dongle server program or service. If multiple network dongles are found by a client, the user may choose one of them when starting up X-Ways Forensics. If one of these dongles is already fully in use, according to the number of licenses that it represents, the user will see that and can choose another dongle. Conveniently, a network dongle can also be used locally just like a regular dongle or multi-user dongle when needed!
• You have the option to order new licenses with a network dongle instead of regular dongles, depending on the number of licenses either for free or at a surcharge. If you own many licenses already, we can offer you to test the network dongle and to swap many or all of your existing regular dongles for a single network dongle. For much more information on the dongles in general and network dongles in particular please see http://www.x-ways.net/forensics/dongle.html#types.
• File System Support
• In newly taken snapshots of HFS+ volumes with hard links, you can now view hard-linked files directly and do not have to look up the corresponding so-called indirect node file manually (the one whose name contains the iNode number, which is specified in the Comments column).
• Newly taken volume snapshots now support a concept of "related" files, related in ways other than a parent-child or sibling relationship. For example, the related file for hard links in HFS+ is the corresponding indirect node file. The related file for files that were found in volume shadow copies in NTFS is the volume shadow copy host file. The related file for a volume shadow copy host file is the corresponding snapshot properties file (called "snapprop" in the Type column). More kinds of n:1 relationships are conceivable in future versions. Files for which a related file is defined get their icons marked with a small blue downward pointing arrow on the left-hand side.
• A new command in the directory browser context menu (Navigation submenu) allows to conveniently find the related file if one exists for the selected file. You may also press Shift+Backspace to navigate to the related file. This is similar to just hitting the Backspace key, which navigates to the parent file or directory.
• For files found by v17.0 and later in volume shadow copies, the Attr. column now points out the sequential number of the snapshot in which they were found, as indicated by the snapshot properties file.
• Avoids more irrelevant identical traces of files found in volume shadow copies.
• In newly taken volume snapshots of NTFS volumes, hard-linked files now get a special treatment. An additional hard link that merely provides a short filename to satisfy the 8.3 requirements of old Microsoft DOS/Windows versions is not counted any more as a hard link. Instead, such files get their hard link count marked with a ° in the Links column of the directory browser. That way, the hard link count more accurately reflects the hard links actually present in the volume snapshot of X-Ways Forensics, and normal files always have a count of 1, whereas 2 or more really means something more special.
• A filter is now available for the ID column, which makes it more convenient to find other hard links of a given file (except HFS+).
• When viewing a hard-linked file in file systems with direct support for hard links (not HFS+), the other hard links of the same file are now optionally marked as already viewed as well at the same time, just as known in previous versions for duplicates based on hash values.
• When creating report table associations for duplicates of the selected files at the same time, this now includes other hard links of the same file (except in HFS+).
• Support for more deeply nested subdirectories on Ext* volumes.
• Searching
• In newly taken volume snapshots of NTFS volumes, all "real" hard links (i.e. hard links other than SFN) except for one can be conveniently excluded from logical searches and indexing . Nowadays on Windows installations often between 10,000 and 100,000 hard links of system files exist, for example 27 links to a file like "Ph3xIB64MV.dll" in directories such as
• \Windows\System32\DriverStore\FileRepository\ph3xibc9.inf_amd64_neutral_ff3a566e4...
• \Windows\System32\DriverStore\FileRepository\ph3xibc2.inf_amd64_neutral_7621f5d6...
• \Windows\System32\DriverStore\FileRepository\ph3xibc5.inf_amd64_neutral_2270382...
• \Windows\winsxs\amd64_ph3xibc9.inf_31bf3856ad364e35_6.1.7600.16385_none_a0a...
• \Windows\winsxs\amd64_ph3xibc5.inf_31bf3856ad364e35_6.1.7600.16385_none_9e7...
• \Windows\winsxs\amd64_ph3xibc12.inf_31bf3856ad364e35_6.1.7600.16385_none_64...
• etc. etc.
• By searching only in one hard link of a file, you can typically exclude several GB of duplicate data and yet don't miss anything if you search all other files. Those additional hard links that are excluded get their hard link count marked with an asterisk (*). Search hits in the only hard link that does get searched are marked with the hint "-> Links" in the Descr. column to remind you of the other hard links of the same file in case those search hits are relevant.
• Support for another artifically defined code page, which allows to search for and read UTF-16 text encoded by the MS Outlook cipher called compressible encryption.
• It is now possible to search and index in up to 6 code pages at the same time.
• The already previously supported non-Unicode artificial code page for MS Outlook compressible encryption now works based on a user-defined code page (by default equal to the code page active in your Windows system for non-Unicode programs), not just Latin 1. Potentially important for languages other than Western European languages. Outlook uses the Windows system code page in its old non-Unicode capable variant of PST.
• PST and OST files are now no longer omitted by logical searches and indexing if the recommended data reduction is active and e-mail and other Outlook data has been extracted from them, but MBOX files are.
• Search hits in all variants of UTF-16 that are not aligned at even offsets are now marked in the Descr. column as "unaligned", as a small hint and explanation why you can read the text only in the alignment-aware context preview of the Search hits column, and not in the text column.
• Logical searches now also specifically cover the transition area from uninitialized (but physically allocated) areas of files to immediately following free space, if the option to cover the transition from slack space to free space is in use.
• Ability to run a logical search in selected files via the directory browser context menu from the case root window.
• File Format Support
• The "Uncover embedded data" function uses some special algorithms for certain file types (Windows.edb, thumbs.db, PLists) and byte-level carving for all other host file types. This carving was limited to embedded JPEG and PNG files in previous versions (+EMF in multi-page printer spool .spl files). Now embedded files of any type whose definition in the File Type Signatures Search.txt file comes with a tilde (~) algorithm and is marked with a new flag "e" (for "embedded") will be carved. As a very good example of this new flexibility, .lnk shortcut files are now carved within customdestinations-ms jumplists.
• Special extraction of objects (pictures and others) embedded OLE2 compound files such as MS Word .doc and MS PowerPoint .ppt, in which previously only JPEG and PNG were found and only through ordinary carving. Embedded pictures are now often output with their original name or designation in the document and are extracted correctly even if fragmented within the OLE2 compound file.
• Exploring the contents of 5 more usually irrelevant zip subtypes is now optional when refining the volume snapshot, compared to just JAR in previous versions.
• Exploring zip-based Office document files such as those of MS Office 2007/2010, LibreOffice, OpenOffice, iWork is now also optional when refining the volume snapshot. Useful if you or the recipients of evidence file containers that you create only wish to see the documents as a whole, no embedded pictures or XML files separately, and don't need to extract metadata from these XML files and can recognize nested documents (documents embedded in other documents) themselves if necessary.
• Support for binary PLists has been improved to include the undocumented CF$UID data type.
• Carving support for "Gatherer Transaction Log".
• Special support for carving thumbcache fragments (CMMM records) at the byte level.
• The resolution of videos is now displayed roughly in the Pixels column after at least one video still has been exported.
• The option to list items in registry hives recursively has been removed.
• Disk Support, Disk Imaging
• The Technical Details Report now checks for certain read inconsistencies that can occur with flash media (for example certain USB stick brands/models, but not others) in data areas that have never been written/used, where the data is undefined. The data that is read in such areas, for example when imaging the media, may depend on the amount of data that is read at a time with a single internal read command. The result is mentioned in the report. If inconsistencies are detected ("Inconsistent read results!" in the report), you will see a message box, which offers to read sectors in smaller chunks from that device as long as it is open, which likely yields the expected zero value bytes instead of some random looking non-zero pattern data when reading such areas. Use of this option does not give you data that is somehow more accurate or original (undefined is undefined and does not mean zeroed out) or contains more or less evidence, it can just have a big impact on compression ratio achieved and reproducibility of hash values with other tools, which may use different chunk sizes for reading and thus produce different data and hash values. Note that it is possible that read inconsistencies occur that are not detected by X-Ways Forensics, because a complete check would be very slow. Again, these inconsistencies are not fatal and not the fault of the software, and they can be explained. Does it mean that you should invoke the Specialist | Technical Details Report command prior to imaging? No, the report is routinely created already when imaging starts.
• Since v16.3 it is possible to reconstruct RAID level 5EE by simply selecting a compatible RAID level 6 variant. Now it is possible to select RAID 5EE systems specifically and reconstruct them also if evencomponent disk is missing. RAID 5EE with forward and backward parity are supported.
• Ability to specify how many extra threads to use when creating .e01 evidence files, when clicking the tiny little button in the lower right corner of the Create Disk Image dialog window. By default X-Ways Forensics will use no more than 4, and it depends on how many processor cores your system has, but you could try to increase it to up to 8 or even 16 on very powerful systems with even more cores usually without problems, for a chance to further increase the speed.
• Detection of Windows dynamic volumes larger than 2 TB on GPT LDM partitioned disks.
• Methodology
• Ability to rank file types by importance/relevance and filter by the rank using the Type Status filter. For example, filtering out those file types ranked #0 or #1 will exclude font files, cursors, icons, themes, skins, clip arts, etc. Files with a low rank are of importance just in very specific investigations, for example source code, in which you would not be interested when looking for office documents or pictures for example, but perhaps when hunting a virus programmer. Higher ranked file types are relevant in more cases. Generally the rank is useful in simple cases where you can expect to find what you are looking for in file types that are fairly well known. As another idea, you could make it a habit to only index files with higher ranks.
• Ability to assign file types to a so-called group, a new concept, which is not identical to a file type category. Useful for example if your standard procedure is to let examiner A check out pictures and videos, examiner B documents, e-mail, and other Internet activity, and examiner C operating system files of various kinds, because of their specializations. You can give these groups meaningful names and filter for them, also using the Type Status dialog window. The groups are displayed in the Type filter.
• The new definitions are all made in the "File Type Categories.txt" file. Existing files of that kind will continue to work as before. Suggestions for ranks are already predefined in the new standard file. Both ranks (from 0 to 9, where missing means 0) and groups (letters from A to Z) can be optionally specified following a tab at the end of a line, in any order, for example as "2P" or "DI3". So up to 10 rank levels are possible (but it is not necessary to fully utilize this range), and up to 26 groups (and you do not have to start alphabetically, the case of the letters is ignored). You can also define ranks and groups for an entire category, following a tab in a category line. To give a group a more descriptive name than just a single letter, insert group definition lines at the end of the text file that start with a equal sign, e.g.
• =P=Photos and videos for image group
• =D=Docs, e-mails and Internet
• =I=File types to index
• Event Analysis
• Event extraction from carved fragments of Gatherer Transaction Log (.gthr2) and existing .NTfy.gthr files, and several other file types. Below is an overview of file formats from which events are currently extracted:
• .firefox (~55) fragments
• _CACHE_001_ and _CACHE_002_
• .lnk shortcuts
• .automaticDestination-ms
• .chrome Chromium cache data_1, data_2
• .usnjrnl fragments
• Registry hives
• .hbin Registry hive fragments
• .doc (last printed)
• .msg
• rp.log XP restore point
• INFO2 XP recycle bin
• .recycler Vista recyle bin
• .snapprop Vista volume shadow copy properties
• .cookie
• .gthr;.gthr2 Gatherer and Gatherer fragments
• .pf prefetch
• JPEG GPS
• OLE2 last modification
• Several events now have an individual description, for example events in the Windows registry and in Internet Explorer index.dat files.
• A filter for the event type column is now available.
• Setup/Administration
• User-specific configurations are now stored in the Windows user profile, in a subdirectory of \AppData\Local\X-Ways. The configuration now becomes user-specific automatically when running X-Ways Forensics not as administrator from a directory on the C: drive where a user does not have write access, such as C:\Program Files. Otherwise by default X-Ways Forensics still runs with a non user-specific configuration so that it remains a portable program and does not unnecessarily alter live systems that you wish to preview/triage. For details please see http://www.x-ways.net/winhex/setup.html. Whether a user-specific configuration is active or not (and if active, for what reason and where it is stored) can be seen in the Help | About box. The reason can be "necessarily" if no write access to the installation directory is available or "forced" if a file named winhex.user is found in the installation directory or "for this user" if the user has an individual configuration already from previous executions for either of the other two reasons. The inconsistent use of Virtual Store subdirectories is now avoided.
• Usability
• Ability to refine the volume snapshot for selected files only, via the directory browser context menu.
• Ability to store most filter and all sort settings in the active case and load them again automatically when a case is opened. See Options | Directory Browser.
• Ability to save filter and sort settings to a separate file and load them again at any time, by clicking on the Open/Save icons on the right-hand side of the caption line of the directory browser. Such files are given the extension ".settings".
• The selected file types of the Type filter are now also optionally stored in cases, like other filter settings. Note that collisions among file type designations become apparent when selections for the file type filter are loaded. For example if you had originally selected "mmf" = "MailMessage File" (category e-mail), then you will find that "mmf" is also selected as "Yamaha SMAF" (category Sound/Music). This is normal and does not change what the Type filter does. When in doubt, the Type filter always also includes other types with the same designation, to avoid that anything is overlooked.
• If you choose to not sort the directory browser initially after start-up, there will now also be no sorting when turning off all filters with a single mouse click, to avoid longer delays when suddenly all files are listed again recursively.
• Ctrl+A now works in all edit boxes and all multi-selection list windows in dialog windows.
• The check for updates can now be found in the Help | Online menu.
• Ability to filter for "unequal to" in the ID and internal ID filters. Useful should the volume snapshot refinement crash with a file that was not part of the volume snapshot when it was last saved during the refinement. In that case you can filter out and omit the offending file with the future assigned internal ID in advance when you try again.
• New Attr. filter option for other virtual files, which includes for example human-readable HTML representations of Internet browser databases, event logs etc.
• Activating Sync mode now automatically deactivates all filters if filters keep the directory browser from listing the file that the current cursor position in Partition/Volume mode is contained in. As always you can click the Back button to return to the previous listing in the directory browser, but remember that this works only if the directory browser has the input focus, not the lower half of the data window where you navigated in Partition/Volume mode, where jumps from one offset to the other can be undone or redone with the Back & Forward functionality.
• Miscellaneous
• Includes the contents of the Pixels column in evidence file containers of the new type.
• If the option to Recover/Copy child objects of selected files is half selected, that now means that the only child objects that will be copied are e-mail attachments.
• When copying files or alternate data streams or other objects that do not have any or all timestamps with the Recover/Copy command, X-Ways Forensics now approximates the fact that a timestamp is not available by setting the corresponding timestamps of the output files to ~0 (Jan 1, 1601 in NTFS). This behavior was already active in versions before April 2012. It can be avoided by holding the Shift key when clicking OK in the dialog box, for example if you wish to use some other programs with these files that do not want to open files with such timestamps (it has been reported for VLC).
• Ability to extract video stills reliably using recent MPlayer releases. MPlayer 1.1 for use with v17 is now provided as a download.
• Directory browser option to display tag marks as check marks.
• The option "Display file sizes always in bytes" can now be found in Options | General | Notation. The alternative .eml preview option can now be found in Options | Viewer Programs.
• Tools | File Tools | Delete Recursively can now automatically delete files for which you do not currently have the right to delete (for example because "Trusted Installer" is the owner), but for which you can get all rights (if you are running WinHex with administrator rights).
• Minimum memory requirements for loaded volume snapshots reduced. More data of volume snapshots can now be kept in memory optionally for higher performance.
• More compact internal organization of certain files in volume snapshots (extracted e-mails, video stills, virtual attached files).
• Volume snapshots from v16.3 (released in October 2011) and later can be imported, from v15.8 (October 2010) to v16.2 as well if no e-mail was extracted by those versions. Incompatible volume snapshot will be identified and not converted.
• Memory requirements for search hits reduced by 17%. Old versions cannot load search hit lists saved by v17.0 and later.
• Many minor improvements and some minor fixes.
• PDF user manual and program help revised and updated for v17.0 in English and German.

Förändringar v16.4 -> v16.5

• File Format Support
• Ability to view browser SQLite databases after generating previews for them using a new option in Specialist | Refine Volume Snapshot | Extract internal metadata, browser history and more. This requires that the files have been checked for their true file type (or are checked at the same time). Supports Firefox history, Firefox downloads, Firefox form history, Firefox sign-ons, Chrome cookies, Chrome archived history, Chrome history, Chrome log-in data, Chrome web data, Safari cache, and Safari feeds, also Skype's main.db database with contacts and file transfers.
• Ability to view Internet Explorer index.dat files after generating previews for them with the same function.
• A permanent preview can now be generated for $UsnJrnl:$J as part of metadata extraction, so that it does not have to be generated on demand when viewing or previewing this journal, which can be potentially time-consuming for large specimen (potentially several GB).
• Ability to generate permanent previews as child objects also for Windows Event Logs (.evt and .evtx).
• The previews are stored in the volume snapshot as child objects, usually in HTML format. These child objects can not only be used internally by X-Ways Forensics for previews of the parent file. You can also view all of them in an external program such as your preferred browser or in MS Excel, by sending these child object to the program of your choice (directory browser context menu). The existence of HTML child objects with searchable text for browser data, event logs and probably more data sources in future releases also improves effectiveness of logical searches and indexing.
• Ability to split HTML tables in the previews of browser databases and event logs after an arbitrary number of rows. You can set this number much higher if you do view the HTML previews externally with your preferred Internet browser and not with the viewer component, which cannot deal with very large tables.
• Ability to view Outlook NK2 auto-complete files, Outlook WAB address books, and Internet Explorer travellog files (a.k.a. RecoveryStore).
• Automatic highlighting of aligned FILETIME values in Disk/Partition/Volume and File mode. Useful when manually inspecting files of various Microsoft formats which may contain more timestamps than can be automatically extracted (try e.g. with index.dat, registry hives, .lnk shortcut files etc. etc.). If the lower half of a data window has the focus and FILETIME values are highlighted, you may also hover the mouse cursor over such a value to get a human readable interpretation of the timestamp. Alternatively, of course, you could get it from the data interpreter if you click the first byte of the value.
• Ability to extract metadata from MS Access database files.
• Metadata extraction from Manifest.mbdx and Manifest.mbdb iPhone backup files.
• Registry report definition files revised. New definition file Reg Report Autorun.txt included.
• Automatic extraction of .lnk shortcut files from automaticdestinations-ms jump lists during volume snapshot refinement.
• Improved ability to deal with corrupt .evtx event log files.
• E-mail Support
• New method for the extraction of e-mail messages and attachments from MSG files, which does not require MAPI.
• Revised extraction of e-mail messages and attachments from DBX and MBOX e-mail archives.
• Revised extraction of attachments from original .eml files.
• PST e-mail extraction slightly improved and completed.
• Ability to select the new extraction methods individually for PST, MSG, DBX, MBOX, and EML. The old extraction method for PST and MSG is a method previously described as "MAPI". The new method for PST was introduced long ago already and is the recommended standard setting. The new methods for all other file types are new to v16.5. The old extraction methods will probably not be offered any more in future versions of X-Ways Forensics.
• Preview available for Outlook Express DBX e-mail archives.
• File System Support
• Support for MBR LVM2 and GPT LVM2 partitioned disks as commonly used by Fedora/Red Hat and also available in Debian and Ubuntu. Single-disk approaches (like the default behaviour when installing Fedora on an ordinary hard disk) and spanned volumes (i.e. logical volumes spanning several physical disks) are supported, the latter require all constituent disks/images to be open in X-Ways Forensics in order to find all data required.
• Ability to reconstruct Linux software RAIDs from partitions. The partitions need to be opened before they can be selected.
• Support for various UDF file system versions and specialties revised and considerably extended: Improved support for UDF when used on media other than optical discs, as well as added support for virtual partitions, metadata partitions, and named streams (the UDF equivalent of alternate data streams from NTFS).
• NTFS FILE record 0x30 attribute timestamps are now displayed in Details mode next to their 0x10 counterparts.
• Fix for NTFS support for media with a sector size of 4096 bytes.
• Ability to recognize the new ReFS file system as such.
• The volume snapshot option "Include files whose clusters are unknown" has turned into one of the infamous 3-state options. If fully checked, all previously existing files of which metadata only is known will be included in a volume snapshot. If not checked at all, those files will be ignored. If half checked, only files for which more than just the name is known (e.g. size, attributes, and timestamps) will be included, e.g. found in index records in INDX buffers or in $LogFile in NTFS, but not directory entry remnants in Ext* or Reiser file systems.
• Image Support
• Support for VMDK snapshot images. The base image and any preceding snapshot images have to be open and interpreted already when interpreting a later snapshot.
• Fixed inability to read from flat VMDK images. Ability to interpret certain VMDK images that previous v16.5 releases could not deal with.
• Ability to create evidence file containers from File | Create Disk Image where some new users may expect that kind of functionality. (X-Ways Forensics only, not WinHex)
• The field to include notes in an .e01 evidence file when creating an image is now larger and allows to use line breaks. Useful if you wish to use it for more information and structure the notes more clearly.
• X-Tensions API
• C++ function definitions for the X-Tensions API are now available for download.
• A plug-in to run Python scripts as X-Tensions can now be downloaded from the X-Tension API web page, along with sample scripts. Also a minimal Python installation is downloadable.
• An X-Tension that during a simultaneous search uses the Luhn algorithm to check sequences of digits for whether they could be credit card numbers (and discards false hits) is now available in 32 bit and 64 bit. When more users create and share their own X-Tensions as we hope, we will create a dedicated web page for X-Tension downloads.
• Ability to load X-Tension DLLs from any directory. By default, X-Ways Forensics expects X-Tension DLL in the directory for scripts and templates.
• Only selected X-Tensions will be executed, not all X-Tensions that were added to the list.
• 7 important new functions were added:
• XWF_Search
• XWF_OpenItem
• XWF_Close
• XWF_CreateContainer
• XWF_CopyToContainer
• XWF_CloseContainer
• XWF_CreateEvObj
• XT_ProcessSearchHit now receives a handle of the item or volume in which a search hit was found, for optional further reading.
• New functionality was added to the XWF_SetItemInformation function.
• More return values for XT_Prepare supported.
• New flag for XWF_OutputMessage function.
• Last parameter in XWF_GetItemInformation API function fixed.
• Usability
• When starting volume snapshot refinements, simultaneous searches or indexing, most other functionality now remains accessible and usable. The directory browser, the case tree and all other user interface elements including all menus remain reasonably responsive most of the time. That means for example you can continue to view files, enter comments about them, add them to report tables, explore directories, activate or deactivate filters, sort files, print files, open and close other evidence objects. BTW, there is an option to minimize the small progress indicator window if you right-click its caption.
• The option to power down or hibernate the computer after completion of imaging or disk cloning is now available in the progress indicator window, so that you can still see during the process whether you had selected it and so that you can still change your mind.
• Multiple dongles attached to the same computer (e.g. terminal server) are now supported, to allow for multiple simultaneous users at the same computer not only with multi-user dongles (cf. http://www.x-ways.net/forensics/dongle.html). Each user can select which dongle to use when starting up the software. The ID of the dongle that he or she had used last will be preselected. The textual notes that are stored in the dongles, if any, will also be displayed to make it easier to identify the right dongle.
• If the only filter that is active is the "naturally active" filter that causes hidden items not to be listed, and when items that are hidden are actually filtered out in the directory browser, then the additional filter icons that indicate an active filter are now displayed in gray, no longer in glaring blue, to reinforce the notion that is it normal that hidden items are not listed and nothing else is filtered out.
• Options in Name filter dialog clarified.
• Path filter extended. Multiple substrings (one per line) are now permitted, and there is a NOT option.
• Virtually attached files now have a paperclip icon.
• Pressing the backspace key and spacebar now work in the case tree.
• File Header Signature Search
• File header signature search: That the start sectors of files that are already known to the volume snapshot are always excluded from file carving is now optional. Of course, X-Ways Forensics still tries to prevent duplicates, but if the file header signature definition or the internal file size detection is strong enough to suggest that a known deleted file was overwritten with a new file, then that new file will be carved although it shares the same start sector with the known file.
• If you intentionally abort the file header signature search or if the file header signature search causes X-Ways Forensics to crash, next time when you start a file header signature search in the same evidence object, you will find an option to resume it right where you had interrupted it, or where it was when the volume snapshot was last saved before the crash occurred (depends on the auto-save interval of the case).
• Miscellaneous
• Ability to only include associations with user-created report tables in evidence file containers, not those created by X-Ways Forensics itself. To make use of this feature, make sure that the option to export report table associations is only half checked when you create a container. This is now also the new default setting.
• Ability to use the General Position Manager in File mode.
• Fixed error that occurred when sorting by the ST# column.
• One more option for the Internal ID filter.
• Many minor improvements.

<<Tillbaka