yes I read up on the syntax of SET idsrc=%~dp0
but after I posted the first post, I guess I was to lazy at first.

Anyway for some reason but I do not think it is the SET idsrc=%~dp0 fault, but the use of CD in script and then .\folders\files reference to copy files. to destination

on my machine it began to copy files from system32 folders an I do belive that the reference to current dir somehow is set to where this commands is located, and therefore by referencing .\folder\files it will copy it from that location. And this turned out to be double true when you used CD inside the script but still not copied the files from that directory (and again on my machine) with no Admin rights.

However by hardcoding the sourcedir to copy from the SET idsrc=J: like I did (where the script is started from), it did copy the files from the CD, the only reason I harcoded the actual (or virtual) CD was that I was launching the script from desktop as I "made it work" for me. So therefore I used J:. The correct way when launched from CD is your way.

Future reference "copy from" I suggest should be %idsrc% though

The & sign somewhere in the code is a "leftover" I forgot to remove, I commented the lines to figure out where things went wrong, like this

SET idsrc=%~dp0&:: Sorry can't use this as reference.

Why? well some of the variables when using this commenting did add a large space at the end so that SET avar=J:\path\to\a folder\ &:: or :: added a long string of space at the end upto the comment.
so when using copy %avar%somefile became "J:\path\to\a folder\.....somefile" (where the dots are spaces) which obviously could not be found, it was a leftover and an error introduced bymyself in my testing.

To the reason to why some backslashes are gone I think we could blame aros-exec CODE block it does not take a single backslash for some reason ? Cpp thing?

That was the reason to why I added the external link to the same code, unfortunatly spelled in Swedish as I was braindead. But it is there.

To make this long story short
make all paths be dependent to a variable constant path like %idsrc%, not a hardcoded relative path like .\Arch

Look up for the quote marks as they tend to be doubled at some points.

//I hope this make more sense now



//A bit later


to the copying of the home.info icon, I copied to default Sys: installation dir which in turn when opening it from inside AROS opens the HOME: drawer

wich is in Windows dokuments as you said, to me it makes more sense to be able to open that folder from inside Aros desktop from that Icon, I could be wrong, but it works. And that is all that matters I think!

@Azvareth

Hmmm. Quite strange, I coded the windows hosted installation script on Windows 10 as well, and it's running fine here. I will check if I included in the distribution the exact final version of the script, although I'm quite sure I did. There are, obviously, some aspects of the script you may have not fully understood.

REM define current directory and destination folder
REM SET idsrc=%~dp0

This command says Windows to set the 'idsrc' variable with the directory the script is PLACED IN (and not the one it's run from). So, if you start it from J:\, you should have idsrc set to J:\. Why this notation? Because a script might might be in a subdirectory and you may start it from the parent one.

ex. script is in C:\pippo\script.cmd
you can

cd C:\
start .\pippo\script.cmd

that way, the "current dir" is still C:\, and every time the script finds instructions like "copy .\blah blah\ to somewhere" it will assume to start from C:\blah blah\ instead of C:\pippo\blah blah".

REM Az
REM this is my CDDrive as I execute this script from outside the drive, change this to the default value above
SET idsrc=J:
REM Az

This is something I really want to avoid. Hardcoded things.


REM Az
REM note no citation marks is apperantly allowed.

Yes. If I left some, maybe I'd delete them and keep paths in variables without. Just a question:

REM SET toolz="%idsrc%.windows"
SET toolz=%idsrc%.windows&

Why have you placed this & in the end?

REM keep the citationmarks as the user could be a double name?

Yes.

mkdir "%idest%"


REM Az
REM xcopy /E /Y * "%idest%" >NUL
REM xcopy needs a given source at my machine as current CD is where I launch the script
REM despite a change of CD in script, so
REM Az
xcopy "%idsrc%" "%idest%" /E /Y >NUL
attrib -R /S "%idest%*"

I guess your syntax for the xcopy command might be better. But, somewhere before, a CD %idsrc% schould have moved the script to the installation directory.

REM Az
REM this line seems to be wrong, what would this do in my windows documents folder?
REM copy "%idsrc%StorageiconsHome.info" "%HOMEDRIVE%%HOMEPATH%Documents"
REM changed to
REM Az
REM copy "%idsrc%StorageiconsHome.info" "%idest%"

It is NOT wrong. For some unknown reason, Windows hosted AROS mounts the HOME: volume not in Windows' standard user profile directory (the parent for Documents, videos, appdata etc), but in Windows' standard folder for user documents. So I had two options here: asking AROS developers to change this behavior, or just assuming that Home: would be the documents folder, at least for this prerelease. And guess what I chose to do?

Moreover, Hosted Icaros NEEDS a hidden ".Icarosd" folder in HOME: (so in the Documents directory, from Windows' POV) to exchange informations from AROS to Windows. This is a future improvement already planned for the future I just haven't had the time to implement in this release. But if you wish to test it, you just need to set the envarc:Icaros/hosted-daemon variable to True before starting the icaros.cmd script, and just echoing any Windows program complete path into home:.icarosd\runme from the AROS side.

REM Az
REM this does also point to wrong place
REM echo start .Archmingw32AROSBootstrap.exe -m %memory% >>"%idest%icaros.cmd"
REM Changed to
REM Az
echo start %idest%Archmingw32AROSBootstrap.exe -m %memory% >>"%idest%icaros.cmd"
more "%idsrc%.windowsicaros2" >>"%idest%icaros.cmd"

Where are backslash gone in those paths?

Quote:
Yes, dokumentet is l?sbart

I have modified the script seems to what seems to copy the files to the correct places. And it will boot but not with 2048 MB for some reason.

I have not tried it yet as it is installing now




I am confused over the HOMEDIR\.icarosd folder though
but anyway, My modifications with comment to why I did it.

I have hardcoded the sourceDir so that need to be changed if you wish to use this script



dokumentet l?sbart?

Hi!

Wanted to report that the Windows hosted installer script (which I assume is: "setup_win_hosted.cmd") unfortunately fails), it seems to copy a lot of files from C:\Windows\System32\ into C:\IcarosDesktop (but not all) with some directories & files from CDRoot\.windows (but again not all)

I checked the script and one thing I do not understand is the line SET idsrc=%~dp0 that is a variable that i cant find

and when trying to launch icaros.cmd (the second phase) it cannot find ./arch/.... and it does not exist.

My system is Windows 10 with no admin rights, however a run installer script as an admin.

I do not use admin rights due to that my kids lately have downloaded ad/spy ware onto the computer that was a h*ll to get exterminated.

Do you have any suggestions? what am I doing wrong?

//But a great job with the new version. Tested it in VBox looks great but some parts are still "buggy" but is not the fault of the distro more to some of the applications itself.

Hi, sorry for being not so useful, however if Icaros fails to start hosed on your Linux machine, you can always run it "native" on a VMware or VirtualBox virtual machine, still running on your Linux box.

I've run Icaros on 64bit Xubuntu, you just need some i386 arch packages - did you try installing libxxf86vm1:i386?

Chris

Whatever Linux distro your running should have some kind of multilib compatibility package.

Sorry, as said i can't help you with linux related issues.

Icaros is 32 bit and based on ABI-v0. Reason for that is software compatibility.

There is a nightly 64 bit linux hosted on the download pages (ABI-v1) in case you'd still like to experiment with AROS (but as you might have guessed 32 bit v0 Icaros executables will not run there).

Only difference between Ubuntu and Xubuntu is XFCE instead of Unity. I did find a solution that got things further along, namely needing 32-bit libs. Now it has issue with libxxf86vm. Probably a 64-bit compatibility issue which pretty much precludes AROS in any form from running on the laptop in question as the laptop has ACPI issues that prevent running AROS natively, and which make it not fuction reliably with 32-bit Linux.

If there was a 64-bit version of Icaros then I could use my other laptop without losing 12gb of ram.