WINE and Linux - List of issues that you may encounter.

[Anobium]

This is a thread to track the know issues and resolutions to using Great Cow BASIC using Linux/WINE. These issue may also apply to any other operating system where WINE is being used to support the Great Cow BASIC Windows build.

[Anobium]

Most issues are not Great Cow BASIC related but they can cause issues when using the IDE or compiler within WINE.

The Wine sub-system does support every command that Windows does. This is causing the following errors.

1. Test scripts to not operate as required.
2. Compilation error messages.
3. User experience not the same as the Native Windows implementation.

So, the following errors are caused.
1. Contextual Help does not operate
2. Help does not launch

Wine also does not support the 8.3 specification for the file system, so,
1. The view demo option does not work.

To resolve I need someone to lead this activity.

Index/Status	Issue
1/Open	Test scripts fail – write a utility or revise the existing script not to use FINDSTR.EXE.
2/Open	Error messages and constant validation of .h files. Fix the MAKEHEX and other scripts – write a utility or revise the existing script not to use FINDSTR.EXE
3/Open	Contextual Help not working. Figure out how to get contextual Help working.
4/Open	Help not working. Figure out how to get Help working.
5/Closed	Enable 'View Demos'. Change the IDE configuration to enable View Demos. Resolution = small change. Change the IDE configuration to the folder name and do not use the 8.3 file convention.

I am sure there are other issues. You edit/add to my list.

[Macgman2000]

Hello Anobium,

I am using PlayOnLinux which is a GUI that helps facilitate wine configuration. I have v0.95 windows version working in Wine. I have the USB recognizing the Arduino Atemel 328p. The compile and download function takes 24s from start to MCU executing (much longer than native windows). When I tried to configure the WinPICpgm bat file just as I did for the avrdude, it will not launch. I tried everything.

-Nick

[Anobium]

@Nick. I cannot reproduce the error. WinPICpgm does spawn as expected. This was tested under Ubunu 64-bit, Wine 1.6.2 with Great COw BASIC v.0.95.007

Can you check versions etc. please?

[Macgman2000]

I am running Ubuntu 14.04 LTS
SYN 6.18.2135
playonlinux 4.2.10
32bit 1.6.2
64bit 1.9.14-staging.

[Anobium]

@Community. Need help here......

[Macgman2000]

I will try to set up a second wine window of SYN tonight, maybe roll back the Wine version to see if it works. Anyway, if I can't get the speed out of compiling as I see on Windows 7, then I will set up a dual boot system.

It would be handy if there was a step by step way to install v0.95 natively, but I think it is too involved and easier to just run Wine. If that is not true, point me to the info.....

Nick

[Macgman2000]

I created another wine instance for SYN. 64bit 1.6.2, all features seem to work now. I deleted the previous version using 1.9.14 which I think was set up as 32bit.

Anyway, compiling still takes 24seconds for the simple blinking light AVR demo.

Nick

[Anobium]

Good news on setup

Can I confirm that you are using the latest build?

I will assume you are: How long does this take? Manually compile the source file by dropping the source file on gcbasic.exe.

[Macgman2000]

yes I have the latest build, I will verify when I get home again.I have timed it at 24sec from when I click to compile and download until the chip executes the code. On a windows 7 desktop engineering station it takes 4 seconds start to program execute on the MCU. I did an apples to apples set up.

I will try dragging over the source and dropping it on gcbasic.exe.

[Anobium]

Ok. I will wait for results. If you can drag and drop, I couldn't figure out how to do it.... let me know. ☺

[Macgman2000]

I tried your suggestion, same issue. I have since set up a dual boot Ubuntu 16.04 LTS and Win 10.
I have given up on getting it to work in Linux (sorry), my GF is starting to give me subtle hints this is taking a lot of my time...LOL. On the upside, Win10 compiles just as well as Win7.

-Nick

[mkstevo]

I can't comment for Linux, but can confirm that it takes longer to compile a program under WINE on my Mac, than it does on a VirtualBox installation on the same Mac.

The latest version (0.95.007) is quicker than the previous versions but still significantly slower. On random occasions it seems much quicker, but mostly not.

The major delay seems to be in loading the 'includes'.

             include\\3pi.h
             include\\ADS7843.h
             include\\ALPS-EC11.h
             include\\chipino.h
             include\\DHT.h
             include\\DS1307.h
             include\\DS1337.h
             ...

Then further delays as these are 'found'.

Finding source files:
D:\Program.gcb: found
D:\Program.h: found
C:\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\a-d.h: found
C:\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\pwm.h: found
C:\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\rs232.h: found
C:\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\eeprom.h: found
C:\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\sound.h: found
C:\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\stdbasic.h: found
C:\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\7segment.h: found

The actual compilation seems reasonably quick by comparison to the loading and finding.

Still. I'm a patient man. If it takes 90 seconds to compile, it takes 90 seconds. I can wait. Especially now I can use my programmer without needing to start Windows. The Pickit3 programmer under the Mac is far faster than my Windows GQ-4X programmer so I suppose what you lose on one, you gain on the other...

With the original makeHEX.bat:

 33.1  Sec.    Compiler Version: 0.95 2016-07-03   Program Memory: 3657/8192 words (44.64%)   RAM: 87/1024 bytes (8.5%)   Chip: 16F1829

Editing the makeHEX.bat file so that the for /R include\ %%F in... portion of the batch command isn't done dramatically speeds up the compile.

With the modified makeHEX.bat:

  6.8  Sec.    Compiler Version: 0.95 2016-07-03   Program Memory: 3657/8192 words (44.64%)   RAM: 87/1024 bytes (8.5%)   Chip: 16F1829

So it does appear to be the commands:

for /R include\ %%F in (*.%FileType%) do (
    REM Remove next line if you want to see the files as they are Processed.
    rem echo              %%F
    attrib "%%F" | findstr /B "A"  > nul
    if errorlevel 1 (
    rem do nothing - move onto next action.
    ) ELSE (
  REM Show file being processed
    echo              %%F
    ..\G+Stools\gawk.exe -v NoHeaderMessage=1 -f ..\G+Stools\preprocess.awk  "%%F"
  REM Set the attrib bit, so, we know we have processed this file.
    attrib "%%F" -A
    )
)

That are causing the delay. Sadly I have no idea whether these commands need to be carried out each time.

I have re-compiled a version of G+Stools that has an additional option to call a modified batch file (QuickHEX.bat) in which I've removed the 'slow' processes. This means that if I select 'makeHEX' the original batch file (makeHEX.bat) is run, if I select my new command 'QHex', the new batch file is run. In the event of the 'slow' commands being needed, I will be able to use them. The command I've added to G+Stools requires it to have the parameter 'quickhex' in place of plain 'hex' to call the new file. If anyone is interested, I'll gladly upload my modified files. The modified files are simply copied into the WINE C:\GCB@SYN\G+STools directory. I'd recommend that anyone doing so, backs up the contents of this directory, just in case...

[Anobium]

I think I know the issue. It may be fixable. Send me a PM, I need your email address. I will provide you a file that 'may' sort the issue.

Ever hopeful!

[Anobium]

That was what I was to change. ☺

[mkstevo]

The modified files I referred to are linked to in the following post:

Modified tools thread

The compilation time is speeded up by about five times by bypassing the validation of the header files. By adding an option to G+Stools either the original (slow) compile takes place, or the new (faster) compile. The optional faster compile can be added to the external tools menu of SynWrite making the choice of quick or slow compilation a mouse click away.

[Macgman2000]

I find myself really compelled to get this WINE thing figured out for Ubuntu. I bought a second drive for my laptop, set up Windows 10 and Ubuntu 16.04 LTS dual boot. Both run beautifully. I want to get GCB to run just as fast during compiling as it does on Windows.

I don't have any experience "compiling" linux code to get it to work natively on my Ubuntu. Haven't truly looked too much into it either. There has to be a happy medium though......or maybe someone has a step by step on how to get GCB to work natively in ubuntu?

[Anobium]

Can you try just dropping a source file onto Gcbasic.exe? What is that time like? So , no longer includes   any thing else. If you cannot drag and drop please use the Wine command line and pass the source file as a parameter.

[mkstevo]

I find running GCB under WINE (Mac) is a better proposition than VirtualBox, if only to avoid Microsoft. In almost all other respects, VirtualBox is superior. VirtualBox also supports more programmers than the Mac meaning a fast compile in WINE might lead to a wait for VirtualBox to program the device. If I could get GCB to run natively on the Mac that would be better still, but as that isn't currently possible, WINE it is for me.

While I've spent a little time speeding up the compile time under WINE, it is more sheer bloody mindedness in trying to get to the bottom of the reasons for the delay. I can live with the slow compile if I have to, but I like to know I've done my best to find the reason why and that it isn't something I'm doing wrong.

[Anobium]

I am running Ubuntu 16.04 LTS. Not seeing same issues. Is this RAM? Disc technology?

I would like the results of the performance test, see above, I am concerned about not understanding the root cause of the issue. We can then fix going forward.

[mkstevo]

I have been trying to get "Help" working for GCB within a Wine environment. I have managed to make some headway. Though what I've done isn't perfect, it does make help more useable.

Even after modifying the 'CallCHM' file extensively, I couldn't get the original help in Wine (hh.exe) to do any more than open the start page of the CHM help file, better than nothing I suppose, but I thought I could do better.

I found that SumatraPDF (a PDF Viewer that I've used previously) can open .chm files, and has a command line search facility so I installed this into my GCB Wine environment. I have a Mac, so the instructions are for Macs, I presume that Wine environments on Linux are similar, but there may be some differences.

Download the 32 bit Windows PORTABLE version of SumatraPDF (I couldn't get Wine to install the installed version of SumatraPDF) this comes as a Zip file. [ SumatraPDF-3.1.2.zip ] UnZip this, and place it into a Folder called SumatraPDF. In Finder (the file explorer for Mac) right click on your GCB application and select 'Show package contents'. Open the 'drive_c' folder and copy the SumatraPDF folder (with the SumatraPDF.exe file in it) into the 'Program Files' folder.

Start the GCB Wine application. Select 'Tools > Customise external tools'. Select GCB-Help. To the right of 'Filename' click 'Browse', navigate to the location of the SumatraPDF folder and then click the SumatraPDF.exe file, click 'Open'. In the parameters box, replace any existing text by typing the following:

-named-dest "{CurrentWord}" C:\GCB@Syn\GreatCowBasic\gcbasic.chm -reuse-instance

Note: There are no spaces between '-named' and '-dest', nor between '-reuse' and '-instance'.

I suggest you type it, rather than copying and pasting as when I tried copy and paste, some illegal characters were introduced into the string which caused SumatraPDF to fail to open the help file making me think I'd wasted a few hours of time. Clearly some of this contains the path to the GCB help file, should your path be different this will need to be adjusted. The '-reuse-instance' ensures that SumatraPDF will only open one copy of the help file if a subsequent help request is made, whilst the help file is already open. Click 'OK' to save the changes and exit the Customise tools dialog.

Place the cursor on a GCB token, and press F1, the help file should open, hopefully with the relevant topic displayed. The display of SumatraPDF can be made to fit the Wine window display more consistently by clicking the lower edge of little Menu bars, partially visible on the top left of the 'Tab bar' in SumatraPDF. Select Settings > Options then turning off 'Use tabs'. After SumatraPDF is closed and re-opened the menu bar will look more traditional and is more accessible.

This works, with some minor issues. The problem seems to be that SumatraPDF searches for the selected word where it appears at the top of a topic page. This is good as it means that searching for 'If' returns the page for If...Then and not every occurrence of the word if, but it means that searching for 'Else' yields no results as 'Else' is part way down the 'If...Then' entry, not on an entry by itself. Obviously similar things happen with 'For...Next', searching on the word 'For' brings up the topic, searching on the word 'Next' does not. Bear this in mind and it won't be an issue. As I've been having to have a browser window open showing the online help and I've had to manually search through it every time, finally being able to access help offline is going to be a massive jump in productivity for me.