WIL Extender SDK

[ChuckC]

Just double-checking...

The WIL Extender SDK shows a most recent update of 2011/09/07.

Is that still considered to be the current version, or is there something newer/updated that exists but hasn't been posted as available for download?

[td]

That's it. Interest in extender development is near zero so time has been allocated to other development.

[JTaylor]

I will second that question...

Would love to have a version that has a SLN file for recent versions of VS.     

Also, if you make a sample Extender that has a couple of the DOMExtender functions (Unicode ready) I would probably take that and expand it.  I know that is something people would use.  Me especially


Jim

[JTaylor]

A JSON Extender would be very useful as well.   Something else I would probably do if I had a starting point.   

Jim

[JTaylor]

Wish there was a process in place where people could plug into projects they were interested in advancing.  There are things I would put time in on if it was something that would be folded into the product.  I am by no mean a C expert but I eventually get there.   Would jump at the chance to advance dialogs.   Guessing there are others who might do the same.

Jim

[td]

I will second that question...

Would love to have a version that has a SLN file for recent versions of VS.     

Also, if you make a sample Extender that has a couple of the DOMExtender functions (Unicode ready) I would probably take that and expand it.  I know that is something people would use.  Me especially

The extender interface has not changed in at least 12 years.  The Microsoft Visual Studio conversions are handled automagically by Visual Studio if you have a paid for version.   I think the newer free versions perform the conversion as well but am not sure about that. 

We do not have infinite resources so we have to prioritize our projects.  Staying ahead of the looming changes to Windows is going to be more than enough to keep us busy for a long time.

[JTaylor]

Yeah but you now move at peregrine falcon speed instead of owl speed so you should be good 

Jim

[JTaylor]

Thanks.   Don't have the paid version but hadn't tried VS 2015 since the previous ones didn't work.  2015 did though.   One question...to make it Unicode capable...does that have anything to do with the Extender framework, VS settings or just the code I create?

Jim

  The Microsoft Visual Studio conversions are handled automagically by Visual Studio if you have a paid for version.   I think the newer free versions perform the conversion as well but am not sure about that. 

[ChuckC]

Thanks.

Also, I'll second the question about making extender functions Unicode-enabled w/respect to string parameters.

That's it. Interest in extender development is near zero so time has been allocated to other development.

[ChuckC]

It would be relatively trivial to adapt the C++ implementation of the "nlohman" JSON parser for use in an extender.  However, given the support for making use of the CLR and the .NET libraries, etc.., it would be significantly easier to get fully fledged JSON parser support into a WinBatch script by making use of the Newtonsoft JSON library.  You can get Newtonsoft JSON as a .NET assembly in a NuGet package.

A JSON Extender would be very useful as well.   Something else I would probably do if I had a starting point.   

Jim

[JTaylor]

I need to take a class so I understand how all this works.   I mainly hack my way through this stuff with a dull axe and lots of googling.   Persistence is the only reason I produce anything.   It took me 2 weeks to write the CommControl Extender which was probably only a 4-5 hour job if I had known what I was doing.   I have looked at some of these libraries before for this exact purpose but do not understand how everything fits together and once I throw VS into the mix I am really foundering.

Jim

It would be relatively trivial to adapt the C++ implementation of the "nlohman" JSON parser for use in an extender.  However, given the support for making use of the CLR and the .NET libraries, etc.., it would be significantly easier to get fully fledged JSON parser support into a WinBatch script by making use of the Newtonsoft JSON library.  You can get Newtonsoft JSON as a .NET assembly in a NuGet package.

A JSON Extender would be very useful as well.   Something else I would probably do if I had a starting point.   

Jim

[td]

I think of dotNet assemblies written in C# as just another way to write a WIL extender.   There is no shortage of open source assemblies available for all manner of task.

That said, all of the more recent in-house extenders have been written in C++ and rely heavily on generics.  A few of the older extenders have been converted from C to C++ when they needed a major update.  Most new WinBatch development is also done in C++ with selective use of generic programming techniques.  We would really like to drop support for XP so we could use more of the C++ advanced language features but that won't happen anytime soon. 

Unicode extenders are not difficult to implement.  An examination of the addons.h header file has everything you need to know.  You mostly need to specify Unicode as the datatype for you string parameters and as the output type for returned strings.  If you do that you don't have to worry about string conversions (with one exception explained below.)  The addons.h file has a couple of functions that have both ANSI and Unicode version and you want to make sure you call or implement the one with the "W" on the end.

The one gotcha is that all error strings must be returned as ANSI string so when you pull an error string from your extender's resource area, you will need to convert it to ANSI before you pass it to WinBatch.

[ChuckC]

Thanks again!

One last question about those pesky conversions between ANSI and Unicode.  I note that you write "ANSI" and not "ASCII", so that leads to a question... What code page does WinBatch use for performing conversions?  Does it default to whatever code page is set as a system default, or does it have a hard coded code page that is used?

The one gotcha is that all error strings must be returned as ANSI string so when you pull an error string from your extender's resource area, you will need to convert it to ANSI before you pass it to WinBatch.

[td]

I used ANSI because I am too lazy to write "the Windows codepage of the current user". 

[ChuckC]

Thanks for the clarification.

I used ANSI because I am too lazy to write "the Windows codepage of the current user".

[ChuckC]

Hmm... seems that another question comes to mind...

Looking thru the various archived copies of the WIL SDK that accumulated on my dev system over time, as well as various extenders I've written and may or may not have made any updates to over a span of years, it looks like there's a range of Extender Interface Versions ranging from 2 thru 5, and Feature Levels going back to what might be a deprecated 1001 level, as well as levels 1002 thru 1009.

Does the current release of WinBatch drop support for any of those interface versions and/or feature levels, or does it happily load all extenders with interface version >= 2 and feature level >= 1002?

Also, I noticed that some of the feature level increments had to do with changes in behavior but not necessarily changes in existing data structures, etc..., and so they might not be obvious.  Is there a feature level > 1009, or is that the current high value for it?

[td]

WinBatch will load any extender version as far as I know.   I haven't tried it on an old version 1 extender but I don't know of anything that would prevent it from loading.   There are few old WindowWare extenders that have newer versions and are specifically blocked.   

The latest feature level is 1010.  It is a minor update and should be documented in the addons.h file of the current WilSDK.
 

[ChuckC]

Thanks... Going back to my original post, I realized that I had failed to notice that the most recent WIL Extender SDK that I had on my dev system was slightly older than the current one on the downloads page that dates back to 9/2011.  Now I've got everything up to date.