Visual Studio 2005 express beta. FREE!!!
 

Get it NOW!
[url]http://lab.msdn.microsoft.com/vs2005/get/order/[/url]
You can download online as well, if you have the time.......~8hrs+ for me.

This is a must have for any windows programmer! :showoff:
Or if you just want to debug LLR/PRP/Prime95 with new software.


RMA 2.0 will be written in this superior .net language, and will address many problematic issues of Prime95, LLR, and PRP etc, since they use an older and inferior syntax of C++.
RMA 2.0 will be much like an upgrade pack for all the current primality software available. It is also many other things as well, such as a STATS monster! for enthusiasts!
It is an algorithmic breakthrough in the sense that it quickly can adjust to differences in which a given program(LLR/NewPGen) is utilizing the processor, optimizing CPU-time per Prime. :flex: I have tested this extensively.

:coffee: :coffee:

[QUOTE]RMA 2.0 will be written in this superior .net language, and will address many problematic issues of Prime95, LLR, and PRP etc, since they use an older and inferior syntax of C++. [/QUOTE]

Since that makes no sense you're going to have to elaborate.

I've love to know what these "problematic issues" are that result from Prime95 being written in C (not C++).

[QUOTE=ColdFury]Since that makes no sense you're going to have to elaborate.

I've love to know what these "problematic issues" are that result from Prime95 being written in C (not C++).[/QUOTE]
Yes, please do. Not sure I know what you mean either. On the other hand, I'm still primarily a C programmer ...


Paul

PRP has the problem on lines 1706 2017
ambiguous call to overload.

The VS.net framework properly points out and addresses issues like these easily.
Will it be a painless for George?.... maybe.

That is for PRP, but what of your grand claims about Prime95 and LLR?

If there is a "problem", could not the C code be "fixed"?

Gw
 

That is for PRP, but what of your grand claims about Prime95 and LLR?
If there is a "problem", could not the C code be "fixed"?

Prime95 and LLR have similar ambiguities and security problems(1993), of which, why should I do the work, and list them all for yall.
Besides this was a thread supposed to be about VS.NET for FREE!!

The code most likely can be fixed,.. easier with the correct software.
These projects load as C++. In the source George refers to C, as the older code for which he wishes the SSE2 implementation was still done in...

Currently, I am running LLR safely without fear of stopping/crashing. :showoff:

:question:
BTW George, I am still curious about the function of the hidden form "New"?

[QUOTE=TTn] :question:
BTW George, I am still curious about the function of the hidden form "New"?[/QUOTE]

Probably just some unused form generated by MS VC++ when the project was first created. Some simple default menus and forms are created.

When you get the new compiler, let us know if it can produce 64-bit executables. I didn't see any reference to that in the MS web pages.

64 bit
 

I'll see what I can come up with. Or reference to such.
Luckily it was not back ordered, so I expect 2-4 weeks +.

[QUOTE]These projects load as C++. In the source George refers to C, as the older code for which he wishes the SSE2 implementation was still done in...[/QUOTE]

It doesn't matter what the file is named. It's not C++ if there's no use of classes, polymorphism, etc, etc. Everything I've seen in the Prime95 source is very vanilla C. I have no idea what your sentence about SSE2 means. All the computational code is in assembly.

By the way, .Net isn't a language. It's a series of runtime components that can interface with any language.

...
 

It was created in VS C++ as George says, which made the executable.
We're talking about the same thing here basically.
Have you had a good look at the sources(versions)?

I was also refering to Visual Basic.net, which most certainly is an updated object orientated programming language, from the older Visual Basic 6.0.
I know that it interfaces all languages, because that is how I am learning "The Code", all at once including the new J#. It's real easy to use the help index with full explanations and examples of all, at any time during coding.

If it cant interface LLR/PRP/Prime95 without ambiguity then they are'nt quite up to snuff, or up to date with windows compatibility.
It may be that having .net framework installed, ie 1.0, 1.1, 2.0 causes problems. I'll have to check into that.

Ambiguous References:
Sometimes the names of the .NET Framework Library classes, interfaces, or members are the same as those defined in commonly used header files such as windows.h.

This can lead to naming conflicts or ambiguities in applications that involve interoperating with native code. The following example demonstrates an ambiguous name.

Example
#using <mscorlib.dll>
using namespace System;

#include <windows.h>

int main()
{
return 0;
}
In the above example, the using declaration in using namespace System; makes names from the System namespace accessible to the entire program. One of these names is IServiceProvider. However, windows.h indirectly contains #include servprov.h, which has the following declaration.

typedef interface IServiceProvider IServiceProvider;
Since the using declaration precedes the #include directive, the name IServiceProvider becomes ambiguous.

Solving Ambiguous References
One way to overcome this problem is to include the unmanaged headers first, before any managed using declarations. In this order, the compiler can process the unmanaged headers first and the ambiguity does not occur unless the code uses one of the symbols.

Example
#include <windows.h>

#using <mscorlib.dll>
using namespace System;

int main()
{
// System::IServiceProvider or IServiceProvider via windows.h?
IServiceProvider isp;

return 0;
}
To solve this, you can use fully qualified names for managed symbols.

Example
#include <windows.h>

#using <mscorlib.dll>

int main()
{
System::IServiceProvider __gc* isp1; // fully qualified name
// or
::IServiceProvider __nogc * isp2; // using directive

return 0;
}
As can be seen, we have used a fully qualified name, System::IServiceProvider, to specify the managed name. Generally, it is preferable not to make all names in a namespace available with a using namespace declaration.

In order to run a .net program that uses the .net runtime (most of them),
a PC needs the .net framework (info on 1.1,appears to be the latest version).

XP (may/should ?) have it already.
For the other Windows OSes 98,ME,NT,2000 it is a 23 MB download or from a CD.