I upgraded my machine from WinXP to Win7, and at the same installed Lattice Diamond 3.1. My more complex simulations hang, Active-HDL uses 100% CPU time and is obviously in an infinite loop. Stupidly I don't have the installation of Lattice Diamond 2.1 or 2.2, and unbelievably Lattice only allows you to download the latest version. No fallbacks!
Does anyone have an installation file for Lattice Diamond 2.1 or at a pinch 2.2? I can provide an FTP to put it on if some has. I know its a big file, probably 1G+.
Actually I was able to just copy the Active-HDL 9.2 directory from Win7 in a virtual box on another machine, and overwrite the Active-HDL 9.4 directory. I still wouldn't mind an old installation file but at least I can simulate now. And Diamond 3.1 its actually possible to eliminate bkm warnings and errors. There were 2 many bugs in 2.1, tech support actually admitted my warnings were Diamond bugs not flaws in my code.
Actually I found you can download older version from support -> Software archive
Actual link:
http://www.latticesemi.com/en/Support/SoftwareArchive.aspx
Related
For reasons related to customers with different applications versions i need to maintain in my laptop several versions of Delphi (7, XE 7, XE 8, XE 10.1 Berlin and XE 10.2 Tokyo). My main concern is about PATH variable and problems during compilation and linking time. There'll be any problems ? Do i need to change what ? Any suggestion is most welcome.
I have all versions of Delphi from 7 thru XE8 installed in a single VM and versions 1 thru 6 in another (my Delphi "museum" :)).
The Delphi "museum" is a Windows XP VM to avoid the problems that those older versions of Delphi have with more recent Windows versions. The Delphi 7+ VM started life as Windows 7 VM but has since been upgraded to Windows 8.x and then Windows 10 without any problem.
The two sets of VM's are kept separate in this way to avoid OS complications with those older versions and because I use 1-6 only very, very rarely and version 7+ more often. The precise version at which the "cut-off" was made was determined by the fact that dotted unit names were also only supported from version 7 onward so a lot of the code I ever wrote for 7+ is simply not even usable with 1-6 so there's no point having them alongside each other.
In both cases the IDE/compilers (any version) have no intrinsic problems running alongside other versions.
The only real difficulty is installing Delphi 2006 on Windows Vista (or later). Should you ever need to, this is the only one that presents any real difficulty due to a dependency on .NET which is not handled very well by the installer. But it is do-able and not especially difficult as long as you follow the steps described in detail by Dr. Bob.
Install Locations: Minimising PATH Length/Manageability
With a large number of Delphi versions installed the overall length of the PATH variable can become a problem, but in my experience this is a problem only of manageability. To simplify things on that score and to avoid problems with earlier versions of Delphi on more recent versions of Windows, I installed all my IDE's in a sub-folder directly off the root:
c:\delphi\<version>
Where version is each Delphi version number (e.g. 7.0, 2007, 2009, XE, XE2 etc etc). I then have a number of other folders for shared components:
c:\delphi\bde
c:\delphi\database desktop
c:\delphi\shared files
When I setup the VM I installed each Delphi version in order and changed the installation locations for these components to these locations. In this way there is one common installation of these shared components which is updated by each more recent version as required.
I also have a c:\delphi\common\ folder where I keep things such as pre-compiled FastMM_FullDebugMode.dll etc to be shared across all Delphi versions.
I did all this primarily for my own benefit however, to keep things organised and consistent rather than to solve any particular problem (apart from the previously mentioned issues affecting older versions if installed under Program Files).
e.g. if you simply install into default locations then you will end up with versions "scattered" across Borland, CodeGear and Embarcadero folders. All my IDE versions are in one place.
With or without these considerations, the IDE should be perfectly happy to run all the different versions you mention without any particular configuration required, but you may need to pay attention to configuration/assumptions made by some 3rd party packages/libraries.
3rd Party Packages
Most 3rd party libraries/packages are usually fine, but there may be the occasional one that needs a bit of help. I myself have never come across anything that couldn't be resolved but have to say that I also don't use 3rd party libraries particularly extensively so simply may not have come across any "trouble makers".
In any event, it's unfortunately difficult to give general advice on this point since it obviously depends very much on the 3rd party libraries and the particular "problems" that any particular one might have.
I have all Delphi versions from 6 to 10.2 installed on a computer running Windows 8.1 64 bit. It's not easy to setup, especially for the older versions. The first rule would be: Do not install to "c:\program files", use a separate directory (I use "c:\delphi" with a numerical subdirectory for each version.)
That has two effects:
Older versions, that still write to the installation directory, will work.
The path entries will not be as long (even though, they will be too long after the 5th or 6th Delphi install, see the comments to your question for possible solutions)
Why did I not use multiple VMs? I maintain GExperts for the versions mentioned above and it is too much hassle to maintain the VMs. As long as it works, I will keep all Delphi versions on my computer. If it stops working, I will probably drop GExperts suppport for some Delphi versions.
There are multiple articles on getting older Delphi versions to work on Windows 8.1. They might be useful if you try it.
They are all in the category Windows 8.1:
https://blog.dummzeuch.de/category/windows/windows-8-1/
AFAIK the installation of Lazarus consists from downloading it and FPC from SVN and compiling. There's a problem(*) with the newest versions and I'd like to install a stable version. However, all I have are the SVN revision numbers and I couldn't find out what versions are stable and what work together.
(*) Our application crashes when compiled on Ubuntu 32 and run on OpenSUZE. No idea, what's exactly going on, but this is a too complicated problem for including it in this question.
No, both projects provide releases, and these releases are the only ones formally declared stable, currently Lazarus 1.2.6 (from the 1.2 stable branch) using FPC 2.6.4 (also from stable 2.6 branch).
Lazarus mentions the prefered version of (release, stable) FPC with every release and for 1.2.6 that is 2.6.4.
Of course the status of moving trunk is sometimes more stable than other times, e.g. currently it is quite usable because a new major (FPC) branch is imminent, an event that only occurs once every 2-3 years. But there are no guarantees there, and this branch still must go through the formal release process.
Many users from emerging targets that are not supported in the stable branches often use it though.
I've created an iPhone game which utilizes some code from an old version of the Cocos2D iPhone game development framework and I've got a wee bit of a problem running it on iOS 7.
The version of Cocos2d from which the code was used was probably 0.98.
The actual class is called QuadParticleSystem (in newer versions it's been deprecated by CCParticleSystemQuad).
The actual issue is that the game runs fine on iOS 6 and below. It even runs fine on iOS 7 if the deployment target is set to iOS 6.0 and SDK version set to 7 (at least when put on the device directly using XCode).
The problem is that when the game is uploaded to the appstore, Apple seems to strip out the whole iOS 6 compatibility thing and the particle emitters fail to show up among other things like alpha transitions, invisibility etc.
(They initialize correctly and everything, but they simply DO NOT render).
I've considered (and tried somewhat) upgrading the Cocos2D version, but due to the old third-party frameworks I've used for other things there is a hell of a lot of linking/dependency/deprecation errors which could take forever to fix (if it's at all possible, which I doubt) In other words, I've wasted too much time on the project already and am looking for a quick fix.
If no one knows any solutions could anyone at least direct me to docs where I can see how to create/insert a new particle emitter system in the existing code?
I've thought about using SpriteKit's native emitter system, but I don't know how to incorporate it within the current code (as I've never had dealings with SpriteKit) and am not sure if it's even possible.
I've also thought of maybe upgrading the GL ES framework within that old version of Cocos2D just in case Apple have killed off some functionality of older versions of OpenGL. Then again that could take a while.
I am encountering an issue where nothing is rendered when running a simple OpenGL application through VS 2012 on Windows 8.
I had a little debug renderer I was using to prototype some projects and had it up and running on Windows 7 using VS 2012 Express Edition.
I upgraded to Windows 8, and cloned the git repository with my work on. After installing the latest drivers and installing VS 2012, I ran my application, but nothing displayed, all I get is the screen clear colour. I was getting an exception before but that's because I didn't have the right drivers so when calling glGetIntegerv(GL_MAJOR_VERSION,...) I'd get -1 as OpenGL wasn't set up correctly. It is initialised correctly now and when stepping through, it looks like everything is working fine, the only problem is I'm not seeing anything.
To make sure it wasn't just my code I downloaded some of the Swiftless OpenGL examples and got the exact same thing. My application was using OpenGL 3.2 and no deprecated functionality. My hardware can support up to 3.3, and if it is of any use I am running Window 8 through Boot Camp on a Macbook air.
I have been bashing my head against a wall for the last couple of days trying to solve this but I'm not having much luck, I thought I'd throw it out there to see if anyone has had a similar problem, I'd be really grateful if anyone can offer any information. If someone with Windows 8 could download and build a simple OpenGL application though VS just to see if they can get something up on screen that would be interesting!
Do you use the good old and deprecated fixed function pipeline, namely immediate mode draw calls like glBegin(), glVertex*() and glEnd()? If so, try to draw your stuff using vertex arrays. Even if this doesn't help in your specific situation, immediate mode draw calls should be avoided at all cost to make the code forward compatible. The OpenGL 3.x core profile doesn't contain these old API functions anymore. I had also a blank screen on my new Win 7 notebook (OpenGL 3.3) because of some stale immediate mode draw calls (FTGL).
EDIT:
For independent GL debugging, I recommend this:
http://www.gremedy.com/
This program allows you to pause the execution and investigate buffer contents, shader programs and more.
After installing the latest drivers
Where did you get the drivers from? Only drivers you download directly from the GPU vendor's website ship with proper OpenGL support. The drivers automatically installed by Windows have only poor OpenGL support.
opengl support is not available for windows 8.their are still techniques to use it on windows its better to search on google coz i tried for minecraft game or u can check here too
I've got an old VB4 app I want to look at to convert/re-write into something maintainable.
I have the source, but of course, nothing to compile it with, and VS2010 doesn't like the vbp and won't open it.
Although it installs, it won't run - failing with an out of memory error. I want to try an updated version of Jet 3.0, but I can't seem to get the files referenced in this link http://support.microsoft.com/kb/q151186/
So a few questions:
1) Where is the latest version of Jet 3.0?
2) Is running the app in VB4/5/6 the only viable option to be able to view the forms, designers, etc to convert the app?
1) If at all possible move to Jet 4.0/DAO 3.6 as they have been included in every version of Windows since Windows 2000. It's not worth your while trying to use an older version of Jet with all the install problems you will likely encounter. You might have a few syntax changes to make but I doubt they will be that severe.
2) I have no idea about how good or bad the upgrade path is from VB3 to newer versions of VB. If you don't get an answer here the real long time VB Classic (not VB.NET) experts hang out in http://groups.google.com/group/microsoft.public.vb.general.discussion/topics?hl=en That said the VB6 IDE works well in Windows 7 once you know about one particular install trick which requires creating a 0 byte msjava.dll file in the Windows directory.
1) Where is the latest version of Jet 3.0?
2) Is running the app in VB4/5/6 the only viable option to be able to
view the forms, designers, etc to convert the app?
1 - I'd try to dig up an old copy of Access (or Office)
2 - Actually I doubt it'll even work in vb6 (and vb5 might be an adventure), the project upgrade paths weren't very smooth back then, but yes, you're pretty much stuck. As far as I know there was never anything else that would emulate those designers.
If you can find a version of VB4, or Access 95, then this would come with JET3.
2) Realistically you would need VB4 to have the best chance of opening this. Try to find someone who has some old MSDN disk sets.
You might try a later version. The jump from VB4 to 6 might be too much. I imagine it would open but perhaps not run in VB5 as I presume Microsoft looked at people upgrading projects from the immediately prior version.