Both links for DriversInstaller_Release_6.4.28_Full.7z worked for me.

Romeo91 wrote:

Link
Mirror
MD5: d82a528b9c659cb2433a3f666713cc7b

The VirusTotal analysis he linked from April 28th noted a SHA256 hash of 64ecf28e82f276ce0b61456923a628e206ab8f452286f4decd050c315cf5e7f5

Here is a reanalysis:  https://www.virustotal.com/en/file/64ec … 407495683/
Quote:  "TrendMicro-HouseCall     TROJ_GEN.F47V0603 "
ClamAV calls it a "Possibly Unwanted Application" via "heuristics & reputation engines".

While not necessarily malicious, the scanned file presents certain characteristics which depending on the user policies and environment may or may not represent a threat. For full details see: http://www.clamav.net/index.php?s=pua&lang=en

Goggle Translated Quote of Romeo91:  "As a developer declare no malicious code in this program do not have"

I would be inclined to think that TrendMicro's generic detection, if i have that correct, is likely a false positive.
Be data safe, just in case, if you like.

Updated to include the 3dsp wlan/bluetooth driver from DP_Bluetooth_wnt5_x86-32_1407071.7z

DP_WLAN_wnt5_x86-32_1407111.7z - 30.89 MB   28B40260848C6B174457636DE3A04F3186299B15

edit: link removed - updated below

Perhaps this pack can serve as a "Release Candidate", though not labelled as such.

One pack wasn't enough to get a handle on Bluetooth Stack choices available for my adapter.
  So, it has been split into 6 packs.

for 3rd party DriverPacks folder:
DP_Bluetooth_MS-Misc_wnt5_x86-32_1407111.7z - 6.25 MB   9EDDD842222A76DCB1292BDC330DDE2CFFB4F84B

for post-Windows Setup utilizing SAD3:
DP_Bluetooth_Atheros-Qualcomm_wnt5_x86-32_1407111.7z - 39.58 MB   706AE9477314589F3068DD0EA373FC849B619107
DP_Bluetooth_Broadcom-Widcomm_wnt5_x86-32_1407111.7z - 110.59 MB   7C8CE1B9A34C45B6E7E500E52B2EA93532AC9B26
DP_Bluetooth_IVT_wnt5_x86-32_1407111.7z - 37.17 KB   178C67AA3C6DA58DA26F174F9F720511AE3FB9E3
DP_Bluetooth_Motorola_wnt5_x86-32_1407111.7z - 145.1 MB   216FEEB108823569BB12A288C2EFAD0200F52B6C
DP_Bluetooth_Toshiba_wnt5_x86-32_1407111.7z - 68.02 MB   5F916C9937BDCC7F2677D901610A26BA83E06B0B

*edit:  links removed:  updated below, or only available to Testing Team

A modified .Inf is included in the primary pack (MS-misc) to include support for those Bluetooth Adapters listed in bth.inf from Win7 that are absent from XP SP3.  Another series of modified .Inf files are to follow in aid of supporting the lions-share of HWID's via MS Bluetooth Stack from Win8.x and other preexisting stacks.  None of this requires the inbuilt bth.inf file to be modified.

The IVT pack only has one driver from MSUC, which is incomplete & non-functional AFAICT (although Device Manager doesn't show problems).  Will update later.

Some Win2000 support has been retained via the preexisting Broadcom & Toshiba Stacks.

A reg tweak has been included for mobile hardware to disable remote system wake-up.

Also noting that the freeware BluetoothStackSwitcher doesn't seem to recognize the stacks from Qualcomm-Atheros nor Motorola (for Intel).
  Switching between the (free with WinXP SP2/SP3) MS Bluetooth Stack & the Toshiba (v9.10.25 30day trialware) Stack works very well.

And so ends HWID conflicts within the NT5 branch of Bluetooth DriverPacks.     smile

Acknowledged.

edit ... Here you go.  bluetooth_x64.7z - 8.85 MB
There was no previous x86 NT6 Bluetooth pack, as far as i know.  Your is the first.

155

(5 replies, posted in Vista / 7 DriverPack Mass Storage)

Groeten Meneer X.  Hoe gaat het?

We have a long road ahead to update, yet the first steps of this "thousand mile" journey have already begun.

156

(9 replies, posted in Windows 7 tools)

Yes.  Please.  Do document.
T.E.A.M.=Together Everyone Accomplishes More !     big_smile

Yes, you are correct.
This is likely because the official packs are a little out of date.
Bigfoot has some beta's available from March of 2013 that might work for you.
Be aware that it doesn't support SAD3's "delete irrelevent OS folders" function.

see http://forum.driverpacks.net/viewtopic. … 068#p51068, etc.

We are working to improve the driver packs and can well use and appreciate any help.

I think that was a little off-topic & directed @ me.
[off-topic]  Cheche, that one has been updated to support Oligri's Fritz!WLAN hardware on XP.  [/off-topic]     smile

So, there is indeed a difference. 

Looks like (Vista OR 7) AND (Win 8) are required for development of DriverPacks now.

Say, whatever happened to using x64\Win8\3\BT\Broadcom\1 & 2 as our reference for comparing certification on 7 & 8?    Oh yeah, you "offed" them.  Also, include x64\Win8\3\BT\Intel\1, x64\Win8\3\BT\Marvell\1, x64\Win8\3\BT\Atheros\1 & 2 as examples for consideration.
Roll-back & try again, perhaps.

                        Proposed Changes:
x86:

1) roll-back to DP_Bluetooth_wnt6-x86_1407052
2) The following proposed changes do not take HWID into account:

x86\All\3\BT\Atheros\1		.Cat WHQL'ed for 7 (PE v6.1)btfilter.sys --> Win7
x86\All\3\BT\Broadcom\1		6.1+ in inf --> Win7  (propose new folder name "Broadcom-Widcomm" after 2004 aquisition by Broadcom)
x86\All\3\BT\ConnectSoft\1	.cat - w7 --> Win7
x86\All\3\BT\Marvell\1		.cat - w7 --> Win7
x86\All\3\BT\Microsoft\1	.cat - w7/8 --> Win7
x86\Vista\3\BT\3DSP\1		 --> All
x86\Vista\3\BT\Broadcom\1	* consider --> All
x86\Vista\3\BT\Broadcom\2	* consider --> All
x86\Vista\3\BT\Broadcom\3	* consider --> All
x86\Vista\3\BT\CSR\1		whql'ed for vista (pe headers OSv6.1,Subsysv6.0) dll/sys --> All
x86\Vista\3\BT\Toshiba\1	vista-7 --> All
x86\Win7\3\BT\WIDCOMM\1		whql'd for vista + [WIDCOMM.NTx86.5.1] sys(PE OSv5.0) --> All
x86\Win8\3\BT\Mediatek\1	whql'd for 7/8 sys(PE v6.1) --> Win7
x86\Win8\3\BT\Ralink\1		whql'd for 7/8 sys(PE v6.1) --> Win7 (propose folder "Mediatek-Ralink" after aquisition by MT)
* Server 2008(R2)/2012(R2) requirements should be considered first (leave alone for now?)


3) Null Drivers: (find working driver - or why null-driver necessary)
	x86\All\3\BT\Blackberry\1	&	x86\All\3\BT\OMRON\1
    Note as "Known Issues" for now, if you agree.  (see #8 for potential solution)

x64:

4) roll-back to DP_Bluetooth_wnt6-x64_1407061
5) The following proposed changes do not take HWID into account:

x64\All\3\BT\Atheros\1		.Cat WHQL'ed for 7 (PE v6.1)btfilter.sys  --> Win7
x64\All\3\BT\Broadcom\1		6.1+ in inf --> Win7  (propose new folder name "Broadcom-Widcomm" after 2004 aquisition by Broadcom)
x64\All\3\BT\ConnectSoft\1	.cat - w7 --> Win7
x64\All\3\BT\CSR\1		no support for amd64 in .Inf (PE Head. say 32 bit) --> export to x86 pack (duplicate = delete???)
x64\All\3\BT\CSR\2		.cat - w7 --> Win7
x64\All\3\BT\Marvell\1		(mbts87w7.inf) .cat - w7 --> Win7
x64\All\3\BT\Microsoft\1	[MS.Mfg.NTAMD64.6.1] + .cat - w7/8 (dll PE Header claim supports NT6.0-NT6.2) --> Win7
x64\All\3\BT\Razer\1		rz0???dev.cat can be deleted (x86); retain rz0??????_64.cat
x64\Vista\3\BT\3DSP\1		has .Ntamd64] section in .Inf; WHQL Vista(min.) --> All
x64\Vista\3\BT\Broadcom\1	* consider --> All
x64\Vista\3\BT\Broadcom\2	* consider --> All
x64\Vista\3\BT\Broadcom\3	* consider --> All
x64\Vista\3\BT\CSR\1		whql'ed for vista (pe headers OSv6.1,Subsysv6.0) dll/sys --> All
x64\Vista\3\BT\IVT\1		* consider --> All
x64\Vista\3\BT\Toshiba\1	vista-7 --> All
x64\Win8\3\BT\Mediatek\1	whql'd for 7/8 sys(PE v6.1) --> Win7
x64\Win8\3\BT\Ralink\1		whql'd for 7/8 sys(PE v6.1) --> Win7 (propose folder "Mediatek-Ralink" after aquisition by MT)
* Server 2008(R2)/2012(R2) requirements should be considered first (leave alone for now?)

6)  Also note that in order to support Server 2008, corresponding .Inf files must have a section that ends in .ntamd64  The proposed changes above reflect that.  (see Example:  x64\All\3\BT\3DSP\1 below)

Ordinarily, Server 2008 & 2008 R2 do not support Microsoft's Bluetooth Stack (other stacks or Server 2012(R2) = unknown).
Here is a guide to changing that --> http://social.technet.microsoft.com/For … networking
You could add that link to your "Known Issues" list, if you like.

Also, advise not including any MS OS files, just in case you are unaware of sever consequences possible.
Whilst we are on the topic of licensing, include any license.txt files from original chipmakers/stack owners.  Noting that these drivers are primarily from MSUC, so unless they were in the CAB files, there is nothing to do at the moment.  Just note for future please.

Note too that there may not be any x86-32bit versions of Server, AFAIK.
Having an "All" folder is still a good idea, IMHO.
   Example:  x64\All\3\BT\3DSP\1       

quote from btusbcard64.inf:
[Manufacturer]
%3DSP%=ThreeDSP,ntamd64
[ThreeDSP]
%TDSPUSB.DeviceDesc% = TDSPUSB, USB\VID_05E1&PID_0100&MI_01

[ThreeDSP.nt]
%TDSPUSB.DeviceDesc% = TDSPUSB, USB\VID_05E1&PID_0100&MI_01

[ThreeDSP.ntamd64]
%TDSPUSB.DeviceDesc% = TDSPUSB, USB\VID_05E1&PID_0100&MI_01

7-future)  More about the differing Bluetooth Stacks can be obtained via Wikipedia's "Bluetooth Stack" page.

It may be a worthy strategy to split the Bluetooth pack into packs arranged by Bluetooth Stack author.
Those could be Broadcom-Widcom, IVT-Bluesoleil, MS/misc, & Toshiba.  You will note that there are a staggering percentage of competing HWID's between those Bluetooth Stacks.  It may be necessary to split into multiple packs to target installation of a specific Stack.

8-future) A MS Bluetooth Stack could require a modified .Inf referencing %SystemRoot%\Inf\bth.inf to install support for all HWID's not currently supported by the MS Stack.
Example:  x64\All\3\BT\Broadcom\3\Bcbtums-vista64-J3.*

9-future) Certification may be the tricky part.  At the end of the day, it is only a modified inf.  Support may be limited to Vista-7, if i have that correct.  If so, call it a "known issue" if you agree.
    see:  x64\All\3\BT\Nokia\1\nokiaccx_testcert.cer
I wonder if self-signing would work.  Can we create a "DriverPacks(TM)" Certificate or would a self-created certificate work better?
Something to think about for the future, it would seem.

For a complimentary freeware utility, see http://bluetoothstackswitcher.com/.

- Currently, only configurations with single bluetooth adapter are supported.

Also note, that is a beta being distributed, not a release.

Am glad now that have started NT5 (2k, xp, 2k3) DP_Bluetooth development to compliment your development.
This way, we both learn from each other's development trees (et al).  I'll start a new topic in the Testing area & link what i have as soon as humanely possible.

Consider these as suggestions if you like.  You can use any, all or none of them.  There is no need to credit me.
This pack is "your baby".  From my "donkey-cart" to yours.  I appreciate your efforts.     smile

For now my best recommendation is to roll back both packs to DP_Bluetooth_wnt6-x86_1407052 & DP_Bluetooth_wnt6-x64_1407061.

From there you can safely make those previously mentioned changes irregardless of HWID impact.  After double-checking, that would appear to reflect the OS support available from those drivers.

x86\All\3\BT\Atheros\1		.Cat WHQL'ed for 7 (PE v6.1)btfilter.sys --> Win7
x86\All\3\BT\Broadcom\1		6.1+ in inf --> Win7
x86\All\3\BT\ConnectSoft\1	.cat - w7 --> Win7
x86\All\3\BT\Marvell\1		.cat - w7 --> Win7
x86\All\3\BT\Microsoft\1	.cat - w7/8 --> Win7
x86\Vista\3\BT\3DSP\1		 --> All
x86\Vista\3\BT\CSR\1		whql'ed for vista (pe headers OSv6.1,Subsysv6.0) dll/sys --> All
x86\Vista\3\BT\Toshiba\1	vista-7 --> All
x86\Win7\3\BT\WIDCOMM\1		whql'd for vista + [WIDCOMM.NTx86.5.1] sys(PE OSv5.0) --> All
x86\Win8\3\BT\Mediatek\1	whql'd for 7/8 sys(PE v6.1) --> Win7
x86\Win8\3\BT\Ralink\1		whql'd for 7/8 sys(PE v6.1) --> Win7 (propose folder "Mediatek-Ralink" after aquisition by MT)

Null Drivers: (find working driver - or why null-driver necessary)
	x86\All\3\BT\Blackberry\1	&	x86\All\3\BT\OMRON\1
    Note as "Known Issues" for now.

If you spot any issues (or have spotted), do include very brief notes about them in a seperate section of your changelog titled something like "Known Issues:".  It's always the fastest & easiest DriverPack modification.  Once you have a list of "known issues" then at some point you can eventually work to eliminate some of them,  One other problem with the pack so far deals with known issues with Signing for some included drivers.  More about this later.  Easiest for now simply to note, if you agree.

Do not be discouraged.  You are close to fully understanding and identifying OS Support level by various means.  A "Sherlock Holmes" hat seems a fitting prerequisite, as there can be much manual "detective" work involved with this set of procedures which appear to have thusfar defied automation.  smile

If you can identify any specific drivers in your development tree, point them out to me (& the reader) and we can top up the slope of your learning curve.

I will venture to double-check the x64 drivers now.  Hoping any of this helps.

BTW, have you been able to confirm that effect noted with some Win8 Security Catalogs & Certificates in signed executable files & libraries?

Uh, you might have gone too far in moving things around there.
This is really critical.  Mistakes here = mistakes all down the line ....

Other things to consider before deciding what OS range a driver has.
One of those is the PE Header of the executable files & libraries.  I'm using SilurianSoftware's InspectExe, but it might not support 8 .
Another app i have used is MiTeC's EXE Explorer, but it is likely limited to 7 maximum as well.

Another is the inference(s) for OS support within the .Inf file itself.

MS wrote:

"If you want an INF to explicitly exclude a specific operating system version, product type, or suite, create an empty INF Models section. For example, an empty section named [FooMfg.NTx86.6.0] prohibits installation on x86-based operating system versions 6.0 and higher."
     quoted from:  http://msdn.microsoft.com/en-ca/library … 85%29.aspx

So, if you find such an empty section in an .Inf file, that OS is not supported.

x86 Proposed changes for DP_Bluetooth_wnt6-x86_1407051{built a copy}
     (not taking HWID into account yet - to check), For example:

x86\All\3\BT\Atheros\1		.Cat WHQL'ed for 7
x86\All\3\BT\Broadcom\1		6.1 & greater
x86\All\3\BT\ConnectSoft\1	.cat - w7
x86\All\3\BT\CSR\1		[CSR.NTx86.5.1] = xp & greater = OK
x86\All\3\BT\Marvell\1		w7
x86\All\3\BT\Microsoft\1	w7/8
x86\Vista\3\BT\3DSP\1		could go in all
x86\Vista\3\BT\CSR\1		whql'ed for vista (pe headers OSv6.1,Subsysv6.0) dll/sys --> all
x86\Vista\3\BT\Toshiba\1	vista-7
x86\Win7\3\BT\WIDCOMM\1		whql'd for vista + [WIDCOMM.NTx86.5.1] sys(PE OSv5.0) --> all
x86\Win8\3\BT\Mediatek\1	whql'd for 7/8 sys(PE v6.1) --> Win7
x86\Win8\3\BT\Ralink\1		whql'd for 7/8 sys(PE v6.1) --> Win7 (propose folder "Mediatek-Ralink" after aquisition by MT)

That was all the change that seemed possibly necessary.

Good thing you logged your changes, just in case you need to backtrack!

For future "bonus-points":

Null Drivers: (find working driver - or why null-driver necessary)
x86\All\3\BT\Blackberry\1	&	x86\All\3\BT\OMRON\1]

I've borrowed drivers from your pack for an updated NT5 Bluetooth pack, BTW.     smile
If you spot any from MSUC, put them into a pack for me, if you agree, & i will credit you in changelog.
BTW, don't forget to credit Wo Wo Your Hands in your changelog.  smile

As you can see, building a pack is not always as easy as first meets the eye, neh?
Sorry i didn't get you this info sooner.  Don't want to overload anybody's donkey-cart, so to speak!  tongue

One other thing, please include a copy of your changelog in the x86/x64 folders.
  That's also a good spot for your signature reports too.

If you want, i will review folder moves for OS support for DP_Bluetooth_wnt6-x64_1407052 (etc).

De-linked your first revisions.

Topic continued here -->  http://forum.driverpacks.net/viewtopic.php?id=10835     smile

.NET4 updated, thanks to Ricktendo!

for 3rd party DriverPacks folder:
DP_Graphics_nVidia_GFxp-upd-NET4_wnt5_x86-32_1406091.7z - 102.18 MB   790C2A65C7C89ED6C53AD4E3E08433C879EB4551

edit: link removed - updated or reposted below.

WPPSS!   I forgot one.  Er, make that two.

for 3rd party DriverPacks folder:
DP_DriveProtection_wnt5_x86-32_1405101.7z - 27.57 MB   91BC0459B4DE7CE7D3936687F58C1938B0993288
DP_Misc_wnt5_x86-32_1405111.7z - 40.65 MB   2A5A853426C05489D647677CAD91C9D2F8E2F128

Now SSD installations can easily leave out DriveProtection drivers if they so choose.

Excellent!     smile

BTW, there is a broken link for the x86 Bluetooth pack.

DataFileHost wrote:

"The file you are trying to access does not exist. This might be because the URL you accessed was changed accidentally."

Was the sigcheck executed from Win8.x?
  If so then it is true that some Security Catalogs & other Signatures are not verifiable under lesser OS's.
    In other words, some Security Catalogs & File Signatures meant for 8 will appear "corrupted" under Win7 or less.
The drivers in Win8\3\BT\Broadcom\1 & 2 serve as examples.

BTW, here are the potential updated files.
Bluetooth_x64_drivers_from_WoWoYourHands.7z - 400.9 KB 
    (sha1) 51DA81ABCF28A9EEBF538C328AFB0FF31C9F6751

Careful with that driver, it could be a "land mine".

David Wolters, Moderator wrote:

"I can confirm that the AMDA00 Inteface driver by ASUS is in fact defective"
     [quoted from:  http://social.technet.microsoft.com/For … rohardware

Also see:  http://rog.asus.com/forum/showthread.ph … -driver...

I'll save you the pain and anguish of going through all 27 folders in that collection for the 3 or 4 relevent drivers for x64 only.
Have already simplified it.  Will upload tomorrow, probably after you have uploaded.

Hi again!  How are DriverPack.ini files supported by SAD3 in NT6?
Looking to be able to process exceptions via DPs_Fnshr, if practical (not for chipset/MS though, if i have that correct).

Have also noticed that OS folders supported in SAD3 are:
Server, Vista, Win7 & Win8

When Server is the OS, the Vista, Win7 & Win8 folders are deleted, if selected.
When Vista is the OS, the Server, Win7 & Win8 folders are deleted, if selected.
When Win7 is the OS, the Vista, Server & Win8 folders are deleted, if selected.
When Win8 is the OS, the Vista & Server folders are deleted, if selected.

The All folder is meant to support all of those OS's.
---------------------------------------------------------------------------------
Some other recommendations, if you agree:
-use 7-zip v9.20 settings:  Ultra, Lzma2, 64M, 256, 512M
-delete unnecessary *.cpk, *.exp, *.lib, *.pdb & *.res files
-remove invalid .Cat file in x64&x86\All\3\Bluetooth\Broadcom\4
-remove WLAN drivers from x64&x86\All\3\Bluetooth\Ralink
-remove x64&x86\All\3\Bluetooth\J3 - updated in x86\All\3\Bluetooth\Broadcom\3
-change properties to ensure no read-only files
-if you have Win8, find & run MS's sigver.exe & check + log *.cat, *.dll, *.exe, *.sys & include logs in x64/x86 folder (edit folder to hide tree from public with notepad++ {replace in all open documents})
-there is a preexisting x86 Bluetooth DriverPack by Wo Wo Your Hands.
   I can compile a list of changes, as have updated personal copy & will compare all files before & after Wo Wo Your Hands' few files updated &/or added & upload, if you like.
-(future)look to possibility minimum OS support is not exactly as claimed by MS
   (double-click .cat file to confirm on first page find 4f for minimum OSlevel, also certificates excluding Win8 if not Win8OS {sometimes, possibly}, also to verify checksums of .inf files, architecture - search for [SourceDisksFiles in .inf & any folders listed in [SourceDisksNames for mandatory folders, & to ensure all files exist depending upon architecture, or .inf's are properly named, etc.)
some drivers may need be shuffled to be properly supported (live and learn).     smile

You have made a great start.  Thank you for taking the effort, BTW.

Also, if you are using DP_Misc_wnt6, there is a bug in a driver you may or may not know about.
http://forum.driverpacks.net/viewtopic.php?id=8159  Remove Thpdrv * repack DP_Misc with new date.     big_smile
And, if you support SDD, then HDD Protection drivers in Misc support is unknown, AFAIK.
TrimCheck available elsewhere.

Looks like my question got lost in the shuffle.
   bump --> http://forum.driverpacks.net/viewtopic. … 740#p57740

Release folder path:    ..\x64\All\M\ARECA\
Bigfoot:                      ..\x64\M\All\Areca\

Does SAD3 support this or other changes to folder tree?
  Can it cause some drivers to not be deleted when deleting other OS support?
    Pondering potential pitfalls perplexing pack person.

Also looking for a copy of SAD2 v101203 for potential win2k support.
Is "SAD1" a part of DPs_BASE?

Thank you.

Actually, they have updated today.     smile

That is a generic link too!  Nice.
Am able to download there.  Direct links unavailabe via Realtek, AMD, etc. anyway.

Excellent!     smile

There is one thing i might recommend though, and that is to change the file folder tree to match the 3rd-Party releases.  Example:  http://driverpacks.net/driverpacks/wind … eous/12.02

Correct me if i am wrong please Admin,that might be needed for SAD3 compatibility.

Also,
To avoid confusion, the name should look like:  "DP_Bluetooth_wnt6-x64_1407041" / "DP_Bluetooth_wnt6-x86_1407041"  14=y,07=m,04=d,1=rev
Am changing the name of my personal copy to reflect that.  If you update any of the contents today, call the new one "DP_Bluetooth_wnt6-x64_1407042" please.

Have edited your post to link to your downloads.  Have not yet tried it.  Good work josywong!
That's awesome!

I wonder what happened to lordsepid.  That was quite a tease, if i have that correct.
Altering the name of this topic slightly...

This search should reveal results that are not only NDIS 6.30, by the way.

Are these drivers included in your Bluetooth packs, josywong?

What type of Radio is this?

I cannot search MSUC via my linux OS.  I can download only direct links at this moment.
Am properly licensed, have chose non-MS for iNET though.  My setup is a bit of a mess right now.

Perhaps somebody can direct me as to how to build a 7-based PE disk, unless 8-based PE still works on non-touch HW.  My experience at this point is mostly with NT5, so am a bit of a 'noob here so far.

I like the generic links, though.  Those can help future pack workers too!

175

(7 replies, posted in Other)

Actually, those [REQ]uests are somewhat generic as they force one to search MSU for drivers based upon the HWID in those links.
Whenever those would be updated, can one really say it is fully implimented when newer drivers will be available via those links later?

For those types of generic links, perhaps they could fit under the title [REQ-GEN] (to become [IMPL-GEN]) or by some other means, to support future pack workers?