What about just creating something like "portable" U++, simple .zip which, when unpacked, would run TheIDE from any folder, autoconfiguring everything in the process.

Is it a good idea?

Ah, maybe I should clarify the question...

Is it OK not to have "installer" version? Would save a lot of time...

Mirek

Well, current installer is deeply "illegal" - using .exe to install things was OK 10 years ago, but today .msi is required.

Anyway, before doing that, I have got an idea that perhaps we could try something different. What about just creating something like "portable" U++, simple .zip which, when unpacked, would run TheIDE from any folder, autoconfiguring everything in the process.

mingw would probably now be part of release, otherwise autoconfig would try to setup MSC15 build method. Nothing would be written to the registry, to unistall, all you need to do is to delete the folder.

Is it a good idea?

Mirek

Hi Mirek,

I'm having trouble getting started with this new portable version:

First, unpacking the 7z file takes quite a long time because of mingw is there. (How about a non-mingw variant of Upp? I think I will never use mingw anyway.)

Second, U++ can not find my installed MSC9 and MSC10 SDK compilers (32 nor 64 bit variants). Selecting Setup>Instant setup.. does not help.

Third, I tried compiling UWord with both MINGW32 and MINGW64. Both work in DEBUG mode, but when compiled in Optimal mode, both UWord executables crash on start.

Can you help with these? Edit: I mean especially with getting MSC9 and MSC10 back to work. Dropping MINGW would be a nice option extra...

Best regards,

Tom

Instant setup indeed ignores pre MSC15 compilers. The primary reason is simple: VS 2015 is the first real Win32 C++11 compiler. As we would eventually like to move to C++11, I have decided to force this upon poor users a bit

However, current U++ still supports MSC9 etc, including autosetup: It is hidden behind "Verbose" flag. Activate Verbose you will get legacy autosetup in Setup menu.

Thanks for archive size comment. I seemed OK to me, but this is perhaps the sign that more work is needed there... I guess I can significantly reduce the size, there is a lot of unused stuff there.

Mirek

Hi,

mirek wrote on Mon, 26 October 2015 13:23

Instant setup indeed ignores pre MSC15 compilers. The primary reason is simple: VS 2015 is the first real Win32 C++11 compiler. As we would eventually like to move to C++11, I have decided to force this upon poor users a bit

However, current U++ still supports MSC9 etc, including autosetup: It is hidden behind "Verbose" flag. Activate Verbose you will get legacy autosetup in Setup menu.

Thanks for archive size comment. I seemed OK to me, but this is perhaps the sign that more work is needed there... I guess I can significantly reduce the size, there is a lot of unused stuff there.

Mirek

While on the subject of 'force this upon poor users a bit' could you take a look at Bazaar/Protect from Max? I really need this type of solution and MSC9 is the last compiler to support the current implementation. (Right?) If there is an alternative solution for this task that works on MSC15 compilers, I'd be just happy to upgrade, but meanwhile I will need to stick with the old MSC9.

Best regards,

Tom

Hi Mirek,

Thanks for the tip! Helped a lot.

Even though the MSC9/MSC10 Build method does not have 'Use BLITZ' selected for release mode, I see that there seems to be a considerable amount of BLITZ used in release mode too. While radically boosting compilation times on MSC10, MSC10x64 and MSC9x64, it also results in an internal compiler error on 32 bit MSC9 somewhere in RichText/TxtOp.cpp. The code seems same as before, but disabling BLITZ for RichText in Package organizer allows successful compilation.

Shouldn't the 'Use BLITZ' selection for the build method be obeyed as the default?

Thanks,

Tom

Tom1 wrote on Mon, 26 October 2015 15:34

Hi,

mirek wrote on Mon, 26 October 2015 13:23

Instant setup indeed ignores pre MSC15 compilers. The primary reason is simple: VS 2015 is the first real Win32 C++11 compiler. As we would eventually like to move to C++11, I have decided to force this upon poor users a bit

However, current U++ still supports MSC9 etc, including autosetup: It is hidden behind "Verbose" flag. Activate Verbose you will get legacy autosetup in Setup menu.

Thanks for archive size comment. I seemed OK to me, but this is perhaps the sign that more work is needed there... I guess I can significantly reduce the size, there is a lot of unused stuff there.

Mirek

While on the subject of 'force this upon poor users a bit' could you take a look at Bazaar/Protect from Max? I really need this type of solution and MSC9 is the last compiler to support the current implementation. (Right?) If there is an alternative solution for this task that works on MSC15 compilers, I'd be just happy to upgrade, but meanwhile I will need to stick with the old MSC9.

Best regards,

Tom

What are symptoms? (I have compiled packages fine, after some minor C++11 fixing).

Mirek

C:\Users\tom\Desktop\upp-win32-9081\upp\bazaar\ProtectTest\main.cpp(19) : error C4235: nonstandard extension used : '__asm' keyword not supported on this architecture

Tom1 wrote on Mon, 26 October 2015 15:01

Hi Mirek,

Thanks for the tip! Helped a lot.

Even though the MSC9/MSC10 Build method does not have 'Use BLITZ' selected for release mode, I see that there seems to be a considerable amount of BLITZ used in release mode too. While radically boosting compilation times on MSC10, MSC10x64 and MSC9x64, it also results in an internal compiler error on 32 bit MSC9 somewhere in RichText/TxtOp.cpp. The code seems same as before, but disabling BLITZ for RichText in Package organizer allows successful compilation.

Shouldn't the 'Use BLITZ' selection for the build method be obeyed as the default?

Thanks,

Tom

This is really strange. Can you post a copy of console log?

Mirek

So I tried updating to the new scheme.

Installation took forever from the 7z file and eats up 1 GB.

Automatic setup took again a while and did not find any of my MSC versions.

Running any GUI program and closing it still leaves TheIDE thinking that the application is running and I need to force close it.

This new system does not look production ready at the moment.