SKX Project? Win32::API ?

Dan Rathbun

Note that a few changes are in the works, for win32-api, so as to make using it with either 1.8.x or 1.9.x easier.

See: [#28841] Why not create fat binary gems for all win32 utils gems?
Take note of Daniel Berger's post 3 days ago.

Dan Rathbun

Also... Dan Berger has begun pushing his updates onto the RubyGems server first.
His file list on the RubyForge site, lags behind.

RubyGems for win32-api
Ruby Gems for windows-api
RubyGems for windows-pr

you can manually open the gems with 7z File Manager, and copy files out to do a manual install, if need be.

thomthom

@dan rathbun said:

You don't have a choice.. you must modify it, in order to do what you want.

From what I understood of that license, if I made no modifications at all it could be redistributed as is.

@unknownuser said:

Permissions for Redistribution of the Standard Version

(2) You may Distribute verbatim copies of the Source form of the Standard Version of this Package in any medium without restriction, either gratis or for a Distributor Fee, provided that you duplicate all of the original copyright notices and associated disclaimers. At your discretion, such verbatim copies may or may not include a Compiled form of the Package.

(3) You may apply any bug fixes, portability changes, and other modifications made available from the Copyright Holder. The resulting Package will still be considered the Standard Version, and as such will be subject to the Original License.

Dan Rathbun

@unknownuser said:

(2) You may Distribute verbatim copies of the Source form of the Standard Version of this Package ...

verbatim copies are gem packages with source (sometimes with pre-compiled binaries, rake files, manifest, gemspec.. etc. etc.

Not one file pulled out and installed in the wrong place.

You cannot ignore the other major clause that you do not interfer with a user running a standard version (which would be installed in the correct place, which is one of the Ruby Library folders.)

thomthom

@dan rathbun said:

You cannot ignore the other major clause that you do not interfer with a user running a standard version (which would be installed in the correct place, which is one of the Ruby Library folders.)

What would interfere?

Dan Rathbun

@thomthom said:

@dan rathbun said:

You cannot ignore the other major clause that you do not interfer with a user running a standard version (which would be installed in the correct place, which is one of the Ruby Library folders.)

What would interfere?

I explained it above in this post: http://forums.sketchucation.com/viewtopic.php?f=180&t=34124&p=300656#p300629

thomthom

@dan rathbun said:

Step 2, compile editions for, at least

minGW* mswin32(MSVCRT6)
Or perhaps MSVCRT 7 if you feel all XP should be up to 7 by now.

You can change the so file name after compilation, like api-mswin-60.so (to follow Dan Berger's convention.) That way you can put them all in one subfolder of YOUR plugins lib subfolder:

Ah - I missed this when I was reading your replied the first time.
Compiling it into my own namespace. That's be a safe way of doing it.
Only thing is that I'm not too up to grips with compiling.

Dan Rathbun

@thomthom said:

Compiling it into my own namespace. That's be a safe way of doing it.
Only thing is that I'm not too up to grips with compiling.

Me either.. Ruby is confusing.

The minGW dev kit is supposed to make compiling under that easier.
Some where I thought Dan Berger has instructions for compiling using MS VC/C++

A possible Pure Ruby alternative, is to "steal" the Win32 module INTO your namespace, then remove the temporary toplevel one.

if Win32 has not yet been loaded, load an edition from your TT_Lib subfolder
from within your TT_Lib namespace, call (depending on Ruby ver)

[v1.8.0] Win32 = Object.const_get(:Win32).clone* ['newer'] Win32 = ::Win32.clone

remove the top_level Win32 module, via:
Object.instance_eval('remove_const(:Win32)')
run GC.start

Note that the newset ver of win32-api is now 1.4.7 (but you must get it from the RubyGems site. The RubyForge site only has 1.4.5 available.)

thomthom

What I'm stuck with is compiling it. all tutorials refer to a make command...

thomthom

w00t!
Got it compiled and running!
TT::Win32::API

thomthom

Now, how does the license work for distributing this binary?

thomthom

301 Moved Permanently

(www.opensource.org)

@unknownuser said:

Distribution of Compiled Forms of the Standard Version or Modified Versions without the Source
(6) You may Distribute a Modified Version in Compiled form without the Source, provided that you comply with Section 4 with respect to the Source of the Modified Version.

@unknownuser said:

Distribution of Modified Versions of the Package as Source
(4) You may Distribute your Modified Version as Source (either gratis or for a Distributor Fee, and with or without a Compiled form of the Modified Version) provided that you clearly document how it differs from the Standard Version, including, but not limited to, documenting any non-standard features, executables, or modules, and provided that you do at least ONE of the following:

(a) make the Modified Version available to the Copyright Holder of the Standard Version, under the Original License, so that the Copyright Holder may include your modifications in the Standard Version.
(b) ensure that installation of your Modified Version does not prevent the user installing or running the Standard Version. In addition, the Modified Version must bear a name that is different from the name of the Standard Version.
(c) allow anyone who receives a copy of the Modified Version to make the Source form of the Modified Version available to others under
(i) the Original License or
(ii) a license that permits the licensee to freely copy, modify and redistribute the Modified Version using the same licensing terms that apply to the copy that the licensee received, and requires that the Source form of the Modified Version, and of any works derived from it, be made freely available in that license fees are prohibited but Distributor Fees are allowed.

So, does that mean that when I've changed it to be under my own namespace I can just distribute the .so binary? Simple as that?

Dan Rathbun

@thomthom said:

w00t!
Got it compiled and running!
TT::Win32::API

excellent!

and ya' didn't want to use TNT ? (AC/DC tune running thru my head.)

thomthom

@dan rathbun said:

and ya' didn't want to use TNT ? (AC/DC tune running thru my head.)

Well, I have already been using TT for a while now and all my recent plugins are under that. Trying to void creating more root namespaces.
Though I do like your explosive suggestion.

Thanks for pointing out that it would be re-wrapped like that.

Dan Rathbun

@thomthom said:

So, does that mean that when I've changed it to be under my own namespace I can just distribute the .so binary? Simple as that?

Your compliance: (if you wish, you can ask Dan Berger, what he thinks...)

(4) ... clearly document how it differs from the Standard Version, including, but not limited to, documenting any non-standard features, executables, or modules, ...

Add a README.TXT file that explains:
the TT edition is FUNCTIONALLY still the Standard Version, but namespace wrapped to comply with 4(b)
(4)(b)In addition, the Modified Version must bear a name that is different from the name of the Standard Version.
the Win32 module is loaded as TT::Win32 and the API class is loaded as TT::Win32::API; so as to comply with 4(b)* .. and that the executables are renamed as api_mingw_TT.so and api_mswin_TT.so (or whatever you named them,) in order to comply with 4(b)* you are not marketing or advertising the name "win32-api", and to most endusers, the package's use of this will be transparent.

(4)(b) ... ensure that installation of your Modified Version does not prevent the user installing or running the Standard Version.

Done - because you are loading it into your namespace, AND that namespace will separate your edition from the standard edition, which is loaded into the TOPLEVEL namespace (ie: Object).

(5) You may Distribute Compiled forms of the Standard Version without the Source, provided that you include complete instructions on how to get the Source of the Standard Version. ...etc...

Add to the README.TXT file the links to the RubyForge and RubyGems sites where a user could get the source, and* the instructions as I gave you (above,) on how to module wrap the Standard Version within THEIR OWN namespace.

Add Permission info to the README.TXT:

Because the MODIFIED VERSION only differs from the Standard Version by:

being defined in the TT namespace,

which is for the protection of a normal unmodified Standard installation, * that the TT namespace is for the sole use of Thomas Thomassen,

and that the further modification of the modified version is not feasible, and has no value to any other enduser, unless that user creates a modified version for their OWN namespace from the Standard source code. * and is FUNCTIONALLY still the Standard Version, ... the TT edition is to be considered as a "portability change" under (3) of the License, and that:
"The resulting Package will still be considered the Standard Version, and as such will be subject to the Original License."

So, they have right to use under (1) of the License, viz:

(1) You are permitted to use the Standard Version and create and use Modified Versions for any purpose without restriction, provided that you do not Distribute the Modified Version.
And... include a copy of Artistic License 2.0

thomthom

If the api.so is named differently it doesn't load.
4 said one only had to comply with at least on of the bullets it mentioned - so it'd be ok not to rename the binary then?

Dan Rathbun

@thomthom said:

If the api.so is named differently it doesn't load.

What?

If you have the binary named: plugins/TT/api_mswin_TT.soand you call (from within one of the TT lib files):

require "TT/api_mswin_TT.so"

it doesn't load ??

what is the error message ??

Dan Rathbun

@thomthom said:

(4) said one only had to comply with at least one of the bullets it mentioned - so it'd be ok not to rename the binary then?

problem is you are using (4)(b) which has two provisions listed...

I think it unwise to have your binaries bear the same names as the standard api.so

(You know... there will be people who will copy your binaries some place else.. and then they be crying why doesn't it work? Why doesn't my TT plugins work anymore.. etc. And you'll spend time telling them to put the files back where they belong.. it always happens.)

You want to prevent a similar situation we have with Win32API.so (multiple copies of numerous versions, some compiled as mswin, some as minGW.)

Dan Rathbun

If you must, then before compiling...

rename your modified source file api_mswin_TT.c
.. or perhaps api_mswin_TT_1_4_5.c to include the version (may allow you to distro newer so files without re-releasing the TT.rb file, if you write a "smart" loader that finds the latest version in your plugins subfolder.)

edit the make file if need be and compile.

Do the same for the minGW compilation (name it api_mingw_TT_1_4_5.c )

You understand this whole way.. needs that conditional load ruby snippet I posted at:
http://forums.sketchucation.com/viewtopic.php?f=180&t=34124&start=0#p300530
feel free to:

clean it up* wrap the conditionals into boolean methods* modify the way the so filenames are found by looking for the newest version* etc.

thomthom

I found that the init method in the binary needed to match the name of the binary's filename.
So that is easily taken care of.

But I'm confused about this multiple compiling thing. I didn't have to do that for Vertex Tools. I only compiled once for Windows and once for OSX. No other plugin ship multiple binaries for the same platform.