Adventures in Publishing a QB64 App to the Microsoft Store

[davidshq]

Hi All,

So, I recently successfully published Civil War Strategy Game to the Microsoft App Store. It has been a bit of a trial due to various difficulties and I am wondering if anyone else has a QB64 app in the Microsoft App Store?

The biggest issue I'm still facing is with file management. Windows Store Apps can't save into the same directory where there apps are installed. So I'm in the process of updating the code to use ENVIRON$ to get the LOCALAPPDATA path, append my game directory to it ("cws") and then have it open/save/etc. files in there.

I think I'm pretty close. The one item I'm not sure how to accomplish (simply) is a copy. For example, there are config files which are sometimes changed by the software (cws.cfg for example) and I want to copy the version in the installed directory to the cws folder referenced above. But as far as I can see my main option is using SHELL. Is that so? I'm just wondering if there is a built-in way to handle file copies?

Thanks!

[bplus]

This is very interesting subject given this discussion: https://www.qb64.org/forum/index.php?topic=743.0

Now I am curious what the requirements are?

About file creating, editing, saving... I imagine severe restrictions for security reasons but what if everything is done on users desktop or documents? Still no go?

[davidshq]

It seems they primarily want you to operate out of the user's local app data folder...Though I need to look more into documents/desktop. Operating out of these folders isn't the problem, I'm just wondering best practices for copying a file in QB64. e.g., is there a command in QB64 I can use natively or do I need to execute the command using the QB64 SHELL command?

I did add a few more thoughts to the thread you linked to. :)

[SMcNeill]

Best way is just OPEN file$ FOR BINARY:

SUB CopyFile (source$, dest$)
    OPEN source$ FOR BINARY AS #1
    OPEN dest$ FOR BINARY AS #2
    temp$ = SPACE$(LOF(1))
    GET #1, 1, temp$
    PUT #2, 1, temp$
    CLOSE
END SUB

For a professional app, you'll probably want to do some basic error checking for _FILEEXISTS and _DIREXISTS, but that's the basic process to quickly copy a file.

[Pete]

@Steve:

I meant to tell you some time ago, I really like your:  temp$ = SPACE$(LOF(1)). I got a binary copy routine 15 years ago from the I-Man at the QB forum. It involved setting a fixed length string, and calculating the remainder for the last copy. It was blazing fast in comparison to OUTPUT but had to be run in a loop. This gets the job done in one swipe. Of course, back then memory was limited, so no one would have come up with this method, but with QB64, this is perfect!

Pete

[davidshq]

Code: QB64: [Select]

1. Thanks Steve! Left a [url=https://github.com/davidshq/Civil-War-Strategy-Game/commit/8d209da0a75904a399809f07e7f945ad7ea8dbbf]HT to you in the commit log.

[bplus]

Hey Steve or anyone who might know,

Is there a way to copy an array the same way as with a file, in one gulp? (as opposed to item by item)

I am thinking something like copying a block of memory to another location. Particularly nice would be to allow the copy to be dynamic for REDIM _PRESERVE to be able to work with the copy.

Then, could it not be assimilated into QB64 for a build-in array copy function?

[SMcNeill]

Absolutely.

DIM a(number) AS VariableType
REDIM b(number + 10000) AS VariableType
DIM M AS _MEM, M1 AS _MEM
M = _MEM(a())    <--- notice the brackets after a, making it an array.  a()
M1 = _MEM(b())

_MEMCOPY M, M.OFFSET, M.SIZE TO M1, M1.OFFSET. <--- we just copied all of a() into b(), with even some space left over in b().

[SMcNeill]

And, if you want to make a function to handle the process, you can do something like this:

Code: QB64: [Select]

1. DIM a(1000) AS LONG
2. REDIM b(10000) AS LONG
3.  
4. FOR i = 1 TO 1000
5.     a(i) = RND * 20000
6. NEXT
7.  
8. ArrayCopy _OFFSET(a()), LEN(a()), _OFFSET(b())
9.  
10. FOR i = 1 TO 10
11.     PRINT i, a(i), b(i)
12. NEXT
13.  
14. FOR i = 990 TO 1000
15.     PRINT i, a(i), b(i)
16. NEXT
17.  
18. SUB ArrayCopy (O AS _OFFSET, S AS _INTEGER64, O2 AS _OFFSET)
19. .   $CHECKING:OFF
20.     DIM M AS _MEM, M1 AS _MEM
21.     M = _MEM(O, S)
22.     M1 = _MEM(O2, S)
23.     _MEMCOPY M, M.OFFSET, S TO M1, M1.OFFSET
24.     _MEMFREE M
25.     _MEMFREE M1
26.     $CHECKING:ON
27. END SUB
28.  

There's no error checking or such in the above to reduce performance, so its up to you to make certain that b() is large enough to hold a()..

And, if you notice, we don't even have to declare extra variables AS _MEM in our main program to use it.  We just make certain to pass the OFFSET of a(), the LEN of a(), and the OFFSET of b() to the function.

[bplus]

Thanks Steve,

Oh! I just realized why you set it up as you did, so you don't have to worry about types, I think...

I was hoping to see  arrcopy arr(), copyarr() but you would need to do it for all the types?

[SMcNeill]

Thanks Steve,

Oh! I just realized why you set it up as you did, so you don't have to worry about types, I think...

I was hoping to see  arrcopy arr(), copyarr() but you would need to do it for all the types?

That's the reason, in a nutshell.  Better a routine where you pass offset and size to a second offset,than 20 different routines based on each variable type, in my opinion.  :)

Another way would be to pass 2 MEM variables directly, but that requires you to always point the MEM variables to your arrays before calling it, which really doesn't seem very much simpler to me.