UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
6 Pages V  1 2 3 > »   (Go to first unread post)
   Closed TopicStart new topic
> Access Installer, Access 2013    
 
   
fogline
post Dec 26 2019, 11:00 AM
Post#1



Posts: 200
Joined: 5-August 15
From: Ringgold, GA. USA


I have been using SageKey Access wizard installer for many years
but sad to say they discontinued it this year.
I do not know of any company that has an install made just for installing Access like SageKey did.
Does anybody know of the best Packaging & Deployment install builder software for install Access apps with Runtime.
To distribute to customers.
This post has been edited by fogline: Dec 26 2019, 11:15 AM

--------------------
Ray White - Fog Line Software LLC.
Email
Go to the top of the page
 
theDBguy
post Dec 26 2019, 11:26 AM
Post#2


UA Moderator
Posts: 77,566
Joined: 19-June 07
From: SunnySandyEggo


Hi. The two options that come to my mind are Inno Setup and SSE Setup.

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
isladogs
post Dec 26 2019, 11:28 AM
Post#3


UtterAccess VIP
Posts: 2,189
Joined: 4-June 18
From: Somerset, UK


I use SamLogic Visual Installer Pro. It works well with Access installations but isn't specifically for Access.
Unlike what I've heard about Sage Key, it doesn't stop working when you change Access versions.
Its also a lot cheaper.

--------------------
Colin (Mendip Data Systems)
Website, email
Go to the top of the page
 
GroverParkGeorge
post Dec 26 2019, 11:29 AM
Post#4


UA Admin
Posts: 36,800
Joined: 20-June 02
From: Newcastle, WA


I understand you can acquire their source code and continue to use it "as is".

There are other options, including one called Inno. Although I've not used it, I know other Access developers who do.

--------------------
My Real Name Is George. Grover Park Consulting is where I did business for 20 years.
How to Ask a Good Question
Beginning SQL Server
Go to the top of the page
 
fogline
post Dec 26 2019, 11:32 AM
Post#5



Posts: 200
Joined: 5-August 15
From: Ringgold, GA. USA


Hi DBguy
Haven't talked to you in a few months I hope all is going good for you.
Ya I really hate to see SageKey go out on us, They have a good installer just for Access.
I'm look at a few installers I was just wanting to know what anybody else was using.

Take care my friend take to you soon.

Ray

--------------------
Ray White - Fog Line Software LLC.
Email
Go to the top of the page
 
fogline
post Dec 26 2019, 11:34 AM
Post#6



Posts: 200
Joined: 5-August 15
From: Ringgold, GA. USA


Yes you can acquire their source code for the installer.
I'm just no good with C++

--------------------
Ray White - Fog Line Software LLC.
Email
Go to the top of the page
 
fogline
post Dec 26 2019, 11:35 AM
Post#7



Posts: 200
Joined: 5-August 15
From: Ringgold, GA. USA


Thank you Dogs I'll check that out I never heard of them.. SamLogic Visual Installer Pro

--------------------
Ray White - Fog Line Software LLC.
Email
Go to the top of the page
 
isladogs
post Dec 26 2019, 11:42 AM
Post#8


UtterAccess VIP
Posts: 2,189
Joined: 4-June 18
From: Somerset, UK


You're welcome Fog.
Inno is free but entirely script based.
SamLogic Visual Installer is commercial software.
I'm a happy customer but in no way affiliated with them.
If you do purchase that, make sure you get the Pro version as only that version includes scripting which I use all the time.

--------------------
Colin (Mendip Data Systems)
Website, email
Go to the top of the page
 
FrankRuperto
post Dec 26 2019, 12:47 PM
Post#9



Posts: 664
Joined: 21-September 14
From: (MilitaryBrat) Tampa Bay, Florida, USA


Our users click on a desktop shortcut that copies a frontend master thats located in a sync'd dropbox readonly folder to a hidden folder on each user's PC and then launches the copy. Whenever we release a new frontend version, we just place the new master version in the shared dropbox folder and it gets sync'd to each user's PC.
This post has been edited by FrankRuperto: Dec 26 2019, 12:48 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix and Oracle DB's.
Go to the top of the page
 
isladogs
post Dec 26 2019, 01:21 PM
Post#10


UtterAccess VIP
Posts: 2,189
Joined: 4-June 18
From: Somerset, UK


Frank
Whilst I use a similar system for updating each user's FE from a network copy, that approach isn't sufficient for distributing applications via the Internet.

A professional installer allows you to do far more including specifying file locations, allowing users to choose optional features, adding/editing registry entries, setting trusted locations and modifying BE structure and data.

--------------------
Colin (Mendip Data Systems)
Website, email
Go to the top of the page
 
AlbertKallal
post Dec 26 2019, 06:06 PM
Post#11


UtterAccess VIP
Posts: 2,955
Joined: 12-April 07
From: Edmonton, Alberta Canada


Inno can setup a basic install for you.

However it also has a great programming language that you can use to write code for special things (its Pascal if you are wondering).

So I use Inno but I had to spend time adding in features for Access.

Its free and certain worth the effort if you going to use it for more then "one" install purpose.

there are certainly other possible solutions.

I been using my own Inno scripts. Started out with a simple "zip" file (had a paid copy of WinZip). It could un-zip to a given specified folder. For simple things, this actually worked quite well. And a lot of software used to be a WinZip.exe file (you just click on it - winZip could be packaged as part of the .exe). So end users did not even require WinZip.

Right now?
My Inno installer has 736 lines of code! (that's in the edtior - so blank lines are included in this count).

So I just kept adding feature after feature over the years.

So, it does a lot of things for me.

Detects if the install is on a terminal server. As a result, it don't install the application into drive "C:" anymore.

Detects if Access or runtime is installed - if not, then figures out the correct version to install, and installs it.

Detects if office x64 versions of office/Access are installed.

Looks for, and kills any running copy of Access for when upgrading my software.

Has code for checking the ODBC drivers installed. - if not, then installs them.

And of course for some applications, it has support for installing a "bridge" I have for pushing out invoices to Sage50, Sage 300 and quick-books. (so it looks at current settings, and if a accounting interface is installed, then it it installs my accounting bridge (so it looks for a given accounting package) or can update that software).

I use Inno for all my stuff now.

Installing .net COM objects for use with Access? I need an installer.
Installing .net projects that I created? I need an installer.
Installing Access applications I write? I need an installer.
And of course installing the Access runtime (or if Access is already installed).

In other words, if you developing software then you need a installer. You do not need an installer for JUST one thing, but tons of tons of things you build, you write, you deploy will and can use a installer.

So my thinking here was such a investment is going to be a LONG term investment. It means that one will use the installer for years and years, but MORE important that one will use the installer for MANY different things. This thus falls into what I call "long term" investment. And when I say investment, it not necessary the money, but my time and what benefits I get in return for having spent that time.

So it depends if one is thinking long term, or short term?
The longer the "term" of use, then the MORE I am willing to invest time as opposed to a one-off use of some software.

So, I use my installer for everything. So, for example, one of my Access applications used the ActiveX "PDF" control from Adobe. So the installer would check for the correct version of Acrobat (PDF viewer) and if not, then install the correct version. I mean, if you hunting or go camping? Well a good high qualify set of hiking boots is a great investment.

Same goes for software. If you are ever going to deploy software to some site, then having a installer in your bag of tools is much the same as a good set of hiking boots if you ever go camping.

The best feature of sagekey installer was their launcher, and how it allowed Access to play rather nice when other versions of Access were installed. However, in a lot of years of installing software, I never really had issues with multiple versions of Access having been installed on the target computer.

Now Inno has become a lot easier since I started using it, and it is free. But at the end of the day, to do special things then you WILL have to write code in Inno if you want to customize and do some things beyond a simple installer. Inno programming language is Pascal. However many moons ago I wrote a payroll package in Pascal, and while taking computing science I was exposed to algol-w, and Pascal. So I am comfortable with writing code in Pascal, and thus Inno is a great installer, and I LOVE being able to use Pascal for some small routines and I always liked Pascal as a programming language. So I had a skill set that was being un-used (Pascal), and Inno let me leverage that skill set.

I been meaning to either package up my scripts and sell the source code, or even perhaps post a scaled down "simple" version of the installer for the Access community. However, the issue of support and then fielding questions that are "endless" that I want this one this or that feature during a install? Well, then it becomes too much work to support - even if I have a free version.

The problem is Access deployment is a big challenge, and that explains the success of SageKey and their offerings. However, few now write and deploy commercial software written in Access, so Sagekey is moving on. However, they are selling their source code to their installer. Its c++, and really their launcher is the one thing of value that I would like to get my hands on (as opposed to their installing side of things).

Anyway, regardless of how complex your install(s) are going to be? Inno is certainly up to the task - it just comes down to how much you plan to use the installer for other things then JUST Access. It been worth the time for me, but as noted i had to solve a lot of other issues.

I do recommend Inno but it will take some time to cobble together something beyond a basic simple install. However just to create a folder, create the shortcuts and setup your application (without including the Access runtime, it certainly a good choice. To add run time checking etc. will however require some work and efforts on your part.

I been meaning to post some samples, but I have to "dig out" and remove a lot of extra features I have in my Inno installer else I cause more harm then good!

Anyway, Inno certainly is a possible choice - the amount of effort you put in however will be up to you.

R
Albert


Go to the top of the page
 
fogline
post Dec 26 2019, 06:16 PM
Post#12



Posts: 200
Joined: 5-August 15
From: Ringgold, GA. USA


Thank you for the Info.
I may just get the SageKey source code for $650.00
that way I would have everything in it also the launcher ..

--------------------
Ray White - Fog Line Software LLC.
Email
Go to the top of the page
 
FrankRuperto
post Dec 26 2019, 06:27 PM
Post#13



Posts: 664
Joined: 21-September 14
From: (MilitaryBrat) Tampa Bay, Florida, USA


Are Access ClickToRun or MSI versions also another factor when deploying apps?
What if your installation process encounters errors, do your scripts handle them?
Can powershell scripts be used for custom deployments?
This post has been edited by FrankRuperto: Dec 26 2019, 06:29 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix and Oracle DB's.
Go to the top of the page
 
isladogs
post Dec 27 2019, 02:58 AM
Post#14


UtterAccess VIP
Posts: 2,189
Joined: 4-June 18
From: Somerset, UK


Hi Frank
It doesn't matter which flavour of Access is installed. The installer can install Runtime if needed.
Using suitable script, installers can handle errors.
For example I often distribute both 32-bit and 64-bit ACCDE files in the same installer package.
The script checks the Office bitness and installs the correct version.
Similarly, it creates folders where needed etc...

Not tried running Powershell as I use the built in scripting language.
However I do include/run SQL server script files as part of my installer package so I expect these would work.
Best thing is to check with the program authors.

--------------------
Colin (Mendip Data Systems)
Website, email
Go to the top of the page
 
AlbertKallal
post Dec 27 2019, 09:17 PM
Post#15


UtterAccess VIP
Posts: 2,955
Joined: 12-April 07
From: Edmonton, Alberta Canada


One thing that is coming here?

Well, the runtime (newer versions) are what we call virtual applications. I don’t want to get into a long technical explain here.

But the above quite much explains why SageKey is bowing out here.

We are close (soon) to a system in which you likely be able to install multiple versions of office, and they will all play nice with each other.

We see the “first” rain drops of this change in that runtime 2016 (I think) and 2019 runtimes don’t install the ACE stubs for 3rd party programs. For a VERY long time, just installing the Access runtime would THEN allow any program to use the JET and now ACE database engine. We see now that after installing 2016/2019 runtime, if you want to use ACE say from VB etc., that the ACE engine has to be installed.

So, the Sagekey installer did a bunch of things:

Check for installed versions
Check for x32 vs x64

And a launcher that played “nice” if other versions of Access were installed.

Right now, from Inno, I was with ease to do the first parts (what version – do I want x32 or x64).

However, that last part – the launcher was a gem, as it had some ability to isolate the given runtime install.

However, now that Access runtime is an app-v (virtualised application), then it will interfere less and less with other versions of Access.

As a result, then a good number of “nice” things like shortcuts, what bit version etc. are all great features, but the launcher will be required less and less since office applications and installers are now virtualized.

This means that when you launch say 2016 runtime? Well, exit and now run 2019 runtime. You will notice that “nasty” office is re-configuring prompts are now gone. So, as a result, things are actually improving for Access in this area. This means the value of that launcher is less and less.

Not trying to toss cold water here, but just noting that the one trick part of Sagekey now has less and less value, and is something that I don’t’ really “covet” that much “now”, since access runtime installs have become SUBSTANTIAL more isolated in terms of what it does to a given machine.

So, for example, going ahead and installing a 2016 runtime on a machine that already has 2019 is far less problematic. And in this case? I would not install the 2016 runtime if my installer found a 2019 runtime access anyway.

As noted, there are all these “little” bits and parts and issues (shortcuts, bit size, is access already installed etc.). It is a lot of work to figure out all that stuff.

What was great about SageKey is THEY figured out all these issues for you. I had to do these things on my own!

I wanted to point the above out, as it partial explains why SageKey is exiting this market (part of this is due to the changes they are seeing for the runtime, and those changes are in a direction that means their product is less required). Its also possible with so many versions of the runtime, its becomes a large amount of effort for too little returns on that effort.

Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada


Go to the top of the page
 
FrankRuperto
post Dec 28 2019, 08:10 AM
Post#16



Posts: 664
Joined: 21-September 14
From: (MilitaryBrat) Tampa Bay, Florida, USA


Hi Albert,

This is why I mentioned if C2R and MSI versions was a factor because to me, C2R means that all Office application, Access included, are sandboxed insisde an App-V container. So for example if I install Office 2016 C2R and Office 2019 C2R on the same PC, does that mean there's going to be 2 separate App-V containers on that PC that can't talk to each other? And does it also mean that an Office MSI install cant talk to Office C2R installs, or even co-exist on the same PC?

https://docs.microsoft.com/en-us/microsoft-...v-with-office51

https://en.wikipedia.org/wiki/Microsoft_App-V



--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix and Oracle DB's.
Go to the top of the page
 
isladogs
post Dec 28 2019, 10:42 AM
Post#17


UtterAccess VIP
Posts: 2,189
Joined: 4-June 18
From: Somerset, UK


As the MS article in your post makes clear, you certainly can install both an MSI and a C2R version of Office on the same PC (though its not recommended)
For example I have both Office 2010 and 365 on my main desktop PC.
The important thing is that you must install the older version first and be aware that switching versions can trigger Office needing to 'reconfigure' Office.
That is to reset registry entries

I know nothing about App-V. Should I? Am I missing out by not knowing anything?

--------------------
Colin (Mendip Data Systems)
Website, email
Go to the top of the page
 
FrankRuperto
post Dec 28 2019, 05:57 PM
Post#18



Posts: 664
Joined: 21-September 14
From: (MilitaryBrat) Tampa Bay, Florida, USA


I can see why Microsoft created Office C2R that runs isolated inside an App-V sandbox. One of the main reasons is for security purposes. Maliciously crafted macros or VBA Automation code can wreak havoc on any type of Windows FileSystem, whereas with an App-V container it can only wreck inside the container. The other reasons I imagine are portability, easier for MS to troubleshoot and support.

However, how does one now have to package an Access app that needs to be installed for users who only have Office ProPlus C2R versions?
What happens if the Access C2R version needs to interact with the Win FileSystem for things like storing/retrieving images in folders, or need to integrate a 3rd-party add-in, Oracle ODBC driver, etc?
This post has been edited by FrankRuperto: Dec 28 2019, 05:58 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix and Oracle DB's.
Go to the top of the page
 
AlbertKallal
post Dec 29 2019, 02:53 AM
Post#19


UtterAccess VIP
Posts: 2,955
Joined: 12-April 07
From: Edmonton, Alberta Canada


QUOTE
does it also mean that an Office MSI install cant talk to Office C2R installs, or even co-exist on the same PC?


The co-exist part is better, and getting better.
So in this context, I am suggesting this means the reverse! That multiple editions should become easier and less problematic. But not in the talking part. They can talk to each other – but there is a bridge that been built that allows this.

QUOTE
mean that an Office MSI install cant talk to Office C2R installs


They can now. But, your question is the right one! The issue is “how” they do this, and how “well” you will be able to talk to other office programs.

The problem is right now we have to assume “one” version of Word is the active version of word registered on that computer. So you might have 3 versions of word, but which one will you get with

CODE
CreateObject().


I will explain how this works.

QUOTE
does that mean there's going to be 2 separate App-V containers on that PC


Yes it does. And that has already occurred. They are all in their own special little isolated world now. This also explains some really nasty memory hog issues and posts we are seeing the Office/Access developer community. How this works is a complex subject (has to do with what we call re-entrant code).

Suffice to say, that it was easy to automate (create) say 50 running copies of Excel on your computer with ease. This is due to what we call re-entrant code. This means that ONLY ONE copy of Excel was being launched! The computer was task switching each supposed copy of Excel against that ONE Excel.exe program.

How this works is much like how computers time share, or allow multiple programs to run. You don’t need two copies of windows to run two programs! (All programs running use the ONE copy of windows). So what the OS does is task switches between each program, but they are all using the same copies of windows code to interact with you. (The CPU swaps out the state of the program for each task or even for each users to allow use of the ONE copy of windows).

Turns out this concept was extended to office code! So just like an OS on a computer can have multiple users, or run multiple programs? The same task switching concept was occurring against the ONE copy of Excel in memory. So if you have 5 copies open, and in fact even with 30 Remote desktop users running Excel?

Only ONE copy of Excel would be loaded in memory. Excel was treated like what we call “supervisor” code in mainframe jargon. That means OS code is only loaded once time. So windows in fact treats office code the same way! The time share software stops the program, swaps out the state of the registers and program counter, and then swaps in the next task information, and starts running the SAME code again.

So if the OS can be used by multiple programs running then it stands to reason that code running can be used by multiple tasks or even multiple users. As a result, the OS only ever loaded one running copy of Excel. It “fools” you into thinking that there are multiple copies. Just like windows tricks you into that it can run more than one program.

For older mainframe users here, this is called supervisor mode. In plain English this means one copy of the program was loaded into memory and task switched.

Now with app-v, you find your machine runs out of memory really fast! The reason is that if you launch two copies of Excel in an app-v box, then you actually launched two real copies of Excel.

So after 20-30 copies of Excel launched? You will run out of memory in a real hurry. And we are thus seeing a significant rise in posts in the office user community about running out of memory. I do believe this issue has been addressed now – I just not had time to test. (Hopefully other long time Access and office developers will jump in and tell us in this thread that this is not the case anymore). So, I not spent the time to determine this issue, but others in our community will point out what is occurring.

QUOTE
that can't talk to each other? And does it also mean that an Office MSI install cant talk to Office C2R installs,


They can talk (or better said YOU can talk to these app-v’s. but ONLY one version. But then again, that’s how this worked before C2R anyway. So now only one copy of Excel could be registered. (However the re-entrant code sharing issue is another complex topic that we have to save for another day).


How does CTR allow automation then?

It looks and works like this:
(A slide from 4+ years ago for presentation I did).



So in above if you look at the COM Object Automation box in yellow, it is where ACE “used” to be placed for CTR. But now they moved it over to the right inside of the CTR Virtual box.


So the issue here is how far they take the sandbox they created. We as noted see the up-tick in isolation for Access (and runtime). External programs can’t get at and use the ACE engine unless you install a non app-v version now. OR YOU can download + install ACE separate. (And that’s what really going to occur here).

The way they are dealing with this is shown in the above graphic. They in fact install a more limited set of .dlls in the “COM” box. These .dll’s can then reach into and talk to the app-v. Your automaton is thus now hitting that COM box, and not the applications directly anymore.

But having to install those external .dll’s is a royal pain for Microsoft. They want to get rid of that part of the app-v install, but if they do then long time code that automats outlook or word will break.

So they actually now have the ability to isolate installs, but if they go all the way with isolation then they will break legacy support and doing so will break too much 3rd party software. (We would lose CreateOject() ability).

So the problem is say in access when you go:

CODE
MyWord = CreateObject("Word.Application").


Which of the 3 versions of word installed will you get with above?

Right now? You get the last version of word you ran because when you launch word previous to above, you saw that “please wait while office re-configures” dialog pops up. What that re-configuring is doing is registering the .dll’s for that given version of office. (Or now those .dll’s in that COM box).

Of course if you don’t launch a different version of word, then you don’t see the re-config dialog. So now the “last” version of word used (and registered) is the one you will get with CreateObject()

In the case of app-v, you do STILL see that re-config dialog. They are re-register the correct .dll’s in that external “COM” box.

So Microsoft is STILL registering the correct .dll’s that in turn decides what version of word you will get.

However, note how for Access when you now launch different versions you do NOT see the re-config dialog. (Because there less external shared stuff – like ACE for example).

So now on machines with access 2010, 2013 and 2016 installed? I don’t see the re-config anymore. That’s because 2013 and 2016 are now “more” isolated.

By logic the end result?

I suspect that just like now you have to install ACE separate from Access for use of ACE data engine? (You can’t use the one from the access runtime/full version – it is inside of the app-v and not exposed).

I suspect what will occur is one of two things:

Microsoft will continue to supply that set of “external” .dlls to talk to the app-v. And supply that external set for each version of office. So you be able to work like before (but more memory hogging will occur!!!)

Or, they will just like ACE force you to download an Office automation pack of your choosing. So, if you install say office 2023, if you want 3rd party automation of office? You will have to download and install office 2023 “automation” pack.

The other possible solution is you install the office automation pack, and it ALWAYS plucks out and uses the latest version of office you have installed as app-v. This would be a great idea, but then if you need a specific version of word or Access, you are now in big trouble. (But one has trouble controlling this issue now).

So such a new “COM box” would (should???) always create + give you the latest version of Word installed regardless of the “last” version you ran (assuming all versions are now app-v versions).

So there are a number of approaches that Microsoft will use here. I am not privy as to which above choice will occur.

I’m only one Access developer here. As the “many” in this community deal with above, then they will far outweigh my knowledge. So it will not take that long before this becomes common knowledge in this community.

So I am keeping my eyes open on posts and gathering information on this subject (like everyone else here).
Office will have to continue support of external programs automating office for a long time.

At the end of the day, the march towards office running as app-v will and should provide a better experience, and should allow multiple versions of Word or even Access to be installed, and they should all play much nicer then what we experienced in the past.

And this means that re-registering dialogs when launching a different version of office should appear less and less and eventually be a thing of the past.

So, no doors are being closed here, and such Automation doors can’t be closed due to so much 3rd party software that automates office programs.

Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada
Go to the top of the page
 
FrankRuperto
post Dec 29 2019, 08:04 AM
Post#20



Posts: 664
Joined: 21-September 14
From: (MilitaryBrat) Tampa Bay, Florida, USA


Albert,

As usual, excellent explanation. The main scenarios I see for having multiple Office versions on one box are for development and Office version migration purposes. So in Office C2R versions, does it mean that eventually, or now, we will no longer be able to specifically create, for example, an instance of an Access 2010 MSI application with

CODE
CreateObject("Access.Application.14")


or for example, in Office MSI versions create an instance of an Access 2019 C2R app with

CODE
CreateObject("Access.Application.17")


Or be able to just create a specific version instance within C2R versions, example, an Access 2016 C2R app creating an Access 2013 C2R instance.

Will we be limited to just creating a DAO database object and opening it? What if we need the entire Access, Excel, Outlook or Word object(s) because they're being automated by the Office object that created the instance?

As to deploying Office C2R apps, here's an interesting GitHub repo that uses PowerShell scripts: http://officedev.github.io/Office-IT-Pro-Deployment-Scripts/
It also covers upgrading from Office 2007, 2010 and 2013 to Office 365 ProPlus.
Adding Access Runtime Retail as a valid product
and other goodies
This post has been edited by FrankRuperto: Dec 29 2019, 09:01 AM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix and Oracle DB's.
Go to the top of the page
 
6 Pages V  1 2 3 > » 


Custom Search


RSSSearch   Top   Lo-Fi    28th February 2020 - 10:22 AM