I have created a JavaFX application to retrieve data from a FTDI peripheral device. I used JNAerator to generate the the API and everything works beautifully on my development machine (OS X). However, when tested on a coworker's box (Windows), the BirdJ Pointer.getBytes() method returns byte arrays where every value is off by exactly 128.
Is there a known platform difference or something else in Java that would explain this inconsistent behavior or is this more likely a problem in the native FTDI drivers?
Is there a cleaner way to resolve it than by introducing ugly platform specific logic to modify every byte read or written?
EDIT
I'm not sure my problem description was clear. Here is a specific example.
I request 3 bytes from the FTDI device to confirm it is ready to send data. I get [-91, -1, -1] which matches the documentation saying to expect "A5 FF FF". My code is written to accept that answer and everything proceeds just fine.
My coworker gets [37, 127, 127] which is "25 7F 7F". Since that is not the expected value, my code reports an error and exits.
Calling SetDataCharacteristics to ensure that all words use 8 bits solved my problem.
I've been filling myself up with notes trying to successfully create my first program on Windows 7 with NASM, but with a few self imposed stipulations (until I'm ready to move forward). In creating this first program, however, I have a ton of questions.
.
The stipulations for now are that:
I'm running Window 7 SP1 - 64-bit
I do not wish to use DOSBox so Interrupts 0x21-24 are likely not applicable
I do not wish to rely on C so this is all NASM
I would really like to avoid downloading Visual Studio or associated WDK tools if I can (this depends on whether or not I NEED to interact with the Windows API and relates to Question 2 below)
I've downloaded and installed MinGW
I'm writing my code in Notepad++ and saving as *.asm
I am linking using "ld" for now, but from what I've read, most seem to recommend "GoLink" (and Alink hasn't been updated in years?). I'll probably migrate to GoLink after I've assured myself that "ld" may be too limiting
I want to know if printing is possible without the use of the Windows API or C because of the code below?
.
The only code example that has worked for me in some capacity can be found here.
nasm is not executing file in Windows 8
.
;FILE: main.asm
[section] .text
global _main
_main:
mov eax, 6
ret ; returns eax (exits)
Linked:
c:\Users\James\Desktop>nasm -fwin32 main.asm
c:\Users\James\Desktop>ld -e _main main.obj -o main.exe
c:\Users\James\Desktop>main.exe
c:\Users\James\Desktop>echo %errorlevel%
6
.
My questions (a ton):
The fact that in the code above "ret" by itself gives output, although it just returns whatever is in EAX, is there a way to use it (or another directive outside of the Windows API) to return the contents of a variable (hopefully a string variable)? I tried to use ret with DOS calls, but as noted above, that definitely doesn't work because I'm on a 64-bit system.
In case I absolutely must use the Windows API, is the only way to interact with it by using the WDK tools? Is there some other way because that last time I downloaded Visual Studio and associated WDK tools it took up a ton of memory and massively slowed down my computer. Is there another way to make programs give output or print to the screen either by using internal commands or some other method to use API calls? One thread I admittedly skimmed (amidst 40 more tabs I have open) mentions "Russinovich's Windows Internals" but not a direct answer. At current every time I use code with the extern commands "ld" tells me that the references to commands like WinMain/WinMain#16 are undefined. In the same vein is there a table I can consult containing accurate calls to the API (i.e. _ExitProcess#4 vs. ExitProcess). I found this link to what think may be the NT API but I'm not sure it applies given my stipulations, but in reality, I'm just kind of confused:
http://j00ru.vexillium.org/ntapi/
In bits of code I've encountered I've seen directives for [Bit 16], [Bit 32], and [Bit 64]. [Bit 16] is likely ignorable, but I'm confused by the [Bit 32] and [Bit 64] for the following reasons which may not even be related: Via the code above I'm using the command, "nasm -fwin32 main.asm", then I'm linking it successfully and going on to receive output. For some reason - though I have not read the full "ld" documentation yet - when I use the command "nasm -fwin64 main.asm" and link it in the same way I receive an error saying "main.obj: File not recognized: File format not recognized". I don't understand why differentiating between 32 and 64 while I'm on a native 64-bit machine causes an error although this probably is just unique to ld.
.
In the meantime I'll be reading this question and will post an update it if helps: Executable isn't compatible with 64 bits processor
I can't answer some parts in great detail, so I expect somebody either putting up better answer, or feel free to edit this one.
you are linking against default clib, so your _main is called after Clib is initialized, the ret with value in eax is like return 6; in C++. Then Clib correctly destructs everything and calls windows exit process with exit code 6. You can return only int from _main, and I'm not even sure if full int is propagated to exit process call, or only 8 bit value is used. So you can return single char in ASCII encoding, if you treat that number as char.
You must call Windows API, if you want to display something in console/window, or write something into file, ie. do any output (and of course also for input). There's no peripheral available to win32/64 executable directly, like in DOS CGA/EGA/VGA text modes accessible trough int 10h or video ram at B800:0000. Any try to access some I/O peripheral directly should result into access violation. Only Win API should be legal for user-level application code.
How much of WDK you need I have no idea, haven't developed anything for windows for years. I think it's even possible to create executable without WDK, which would provide correct externs and dependencies on kernel32.dll and similar, but the amount of effort is way beyond simply using proper parts of WDK or clib from MinGW.
I think your linker is set to default to 32b executable, you have to figure out what kind of object format is produced by nasm for -fwin64 and how link that one with ld.
Why the difference. The 64b OS can run 32b binaries. But you can't mix 32/64 in single executable so easily (if at all). So you are either producing 32b or 64b binary, and you have to adjust everything to it (asm instructions used, directives and options, and WinAPI calls).
This is the same question as on turn off FTH but on Windows8 so maybe there's a different answer. I have tried ALL the suggestions there and it still won't go away. I'm trying to debug a 32 bit program on 64 bit Windows Pro 8. I've tried setting all the registry entries (and rebooting); these normally only exist in the 64 bit part but I added them to the 32 bit part as well. I've tried renaming the acxtrnal.dll file (both 32 & 64 bit versions). I've tried running the rundll32 suggestion given. None of these have stopped FTH running and destroying my program performance - an operation which took 5 seconds is now taking several minutes.
The only way I have found to get around it is to rename both the visual studio and my program executables - which I will have to do again when it next starts crashing (which it will - I'm doing development!!).
Any ideas?
To disable it for a single application
Go to the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER versions of
Software\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Layers\your_application.exe and
delete the FaultTolerantHeap entry.
or visit this link
Here
I've been using ESENT for my projects quite extensively and I really love how easy and fast it works. And stable too!!
But I have a HUGE problem with Windows 8!!! Regardless of how I link to the esent.dll (dynamically or statically) whenever I call something other than JetSetSystemParameter, the dll is crashing, takig my app down the cliff.
Unfortunately I still can't get it running. My code had no problem running with Windows 7 or older. But with Windows 8 I get esent.dll crashing when I try to create an instance (floating point invalid operation).
I tried all possible calling conventions. This is definitely NOT the problem. I tried some more and discovered this weird situation: 1. I created a demo application using VS 2012 and JetCreateInstance worked just fine. 2. Exactly the same code in Delphi XE3 will send esent.dll crashing. 3. I created a DLL using VS 2012, exporting the method that worked perfectly in the above demo app, thinking it's a Delphi bug. 4. And then I loaded the DLL in a demo Delphi project (tried with 6, XE2 and XE3). Called the method and BOOM. Same crash.
Now my assumption is that Microsoft won't allow?!? any other developer environment to work correctly with the esent.dll. Is this possible???
The error, a floating point invalid operation, makes the problem sound as though it is related to the floating point control word.
By default Delphi unmasks floating point exceptions. So when code asks the floating point unit to perform operations that result in errors, the FPU signals which is then converted to an exception.
But most other Windows development environments mask these exceptions on the FPU. Such code is written under the assumption that the execution environment has FPU exceptions masked. But if you call a DLL from Delphi, the execution environment will have unmasked FPU exceptions, breaking that assumption. I suspect that if you mask FPU exceptions then your problems will disappear.
To test if this is the problem, you can simply add this to your code, executed early in its life:
Set8087CW($027F);
This will mask all exceptions and set the FPU control word to the default Windows setting.
In the longer term you may wish to mask exceptions before each call to this DLL, and then restore the FPU control word when the call to the DLL returns.
That is a slightly dangerous game using the libraries that are supplied with Delphi since Set8087CW is not threadsafe due to its use of the global variable Default8087CW. If you wish to read more about that issue, I refer you to QC#107411.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I want to start learning Forth (like in the related Stack Overflow question Is it practical to learn and use Forth?). I see that there are many implementations. I would like to use a
ANS 1994 compatible version (if reasonable, but sticking to the standard might be good)
small and compact implementation, I don't want a full OS.
Windows
easy to use, I am new to Forth ;-)
What particular implementation can be recommended?
Win32Forth is really fantastic, as mentioned above. It has a nice integrated development environment and is a pretty modern implementation that seems to match up very well with the standards as well as including some more experimental but widely-accepted features.
I use Gforth, but I also use Vim to edit source files. :) Gforth is good and "classic" as far as the features it supports. It gives you a very "old school" Forth experience without being overly quirky to use. (Some free Forths do odd things with their command lines and such - I use Brodie's "Starting Forth" as the model of how a Forth interpreter should behave.)
I looked at SwiftForth, which is a very nice "high tech" Forth system that goes well beyond what the classic Forths offer in terms of language features and really brings Forth into the modern programming world. If you want to actually do Forth programs professionally, SwiftForth looks like it can handle just about anything you want to do with it.
Some time ago I evaluated 4tH, an implementation of Forth.
I think it meets all of
your requirements. For instance the compiler is only 61 KB. There is also full support for floating point numbers, important if you want to
try to use it for technical/scientific purposes.
4tH runs on most operating systems, including MS-DOS, MS-Windows (both 16 bit and 32 bit), Linux, Coherent, AIX, SunOS, BOS, BSD, Mac OS X, BeOS, RISC OS, etc. Download (Windows installer, 1.5 MB, includes the manual). Manual (PDF, 1.1 MB).
There is an active community centered around the Google Group 4tH-compiler.
For instance today I received two messages.
Please note that in 4tH you can't define your own defining words (words executing at compile time). This is not a serious
limitation, unless you want to cover advanced Forth features.
To get you started (as this is not very clear from the manual or the interactive compile), after installation copy the compiler, 4th.exe, to an empty folder, make two files in this directory, HelloWorld.bat and HelloWorld.4th, and run HelloWorld.bat:
HelloWorld.bat:
4th.exe cx HelloWorld.4th
pause
HelloWorld.4th:
: hello ." Hello from XYZ!" cr cr ;
hello
SwiftForth. It isn't self-consciously small and compact; it just happens to be. It's easy to use (LOCATE WH EDIT , a nicer than usual WORDS), comes with two books, and has an excellent mailing list with over a decade of archives. The evaluation version won't let you compile turnkey apps or DLLs; it still provides an excellent console for a student, and can support scripts in the usual ways. Quick Windows examples:
: sleep-monitor ( -- )
HWND_BROADCAST WM_SYSCOMMAND SC_MONITORPOWER 2 SendMessage drop ;
library dnsapi.dll
( ... DLL imports, constants ... )
variable results
: DnsQuery ( z -- res )
DNS_TYPE_A 0 NULL results NULL DnsQuery_UTF8 ;
: resolves? ( z -- f )
DnsQuery if false exit then
results # DnsRecordListFree true ;
\ an example use of the dialog compiler
\ this compiled DSL is an example of something that 4th
\ precludes with its "not ... serious limitation"
DIALOG (HELLO-ABOUT)
[MODELESS " About Hello" 10 10 120 70
(FONT 8, MS Sans Serif) ]
\ [class text id x y sx xy ]
[CTEXT " HELLO" -1 10 10 100 10 ]
[CTEXT " (C) 1997 Forth, Inc." -1 10 25 100 10 ]
[CTEXT " http://www.forth.com" -1 10 35 100 10 ]
[DEFPUSHBUTTON " OK" IDOK 35 50 50 14 ]
END-DIALOG
Download Gforth for PC and Android.
Tinker with it using it as a calculator, solving simple problems, Fibonacci, solving the quadratic a b c, etc.
I realise they might not meet all your requirements but the following Forth-like languages might also interest you from a learning perspective.
Factor
RetroForth
Additionally, I have found the Re-Factor blog to be a good introduction to Factor.
If you can find a copy of FORTH Inc's old polyFORTH, and an old x86 that can run it, this is the language used in Leo Brodie's original "Starting FORTH". It is a clean and very robust FORTH.
I recommend ciforth, as you're a Windows user the version built for Windows is known as wina: an MS-WIndows NAtive Forth.
ciforth is a small system written in NASM assembler, and comes with a similar interface for a wide variety of systems. It's small, fast, classic (blocks ftw), easy to use as it's old school, comes with a ton of documentation and a wordlist that isn't overwhelming like Gforth's (the wordlist for Lina is here, the only difference between lina and wina are in words that access the underlying OS: linux/MS-Windows).
Gforth has a lot of bloated definitions and some of Starting Forth won't work in it, for example.
The only thing the official release of ciforth lacks is a floating point stack, but Forth can deal with fixed point incredibly well (if one reads Starting Forth, one learns about how to use it).
wina versions can call dll functions just fine, in 32 and 64 bit, but can also make turnkey applications that call dll functions.
Beta releases have floating point as a loadable extension.
Win32Forth worked well for me.
durexForth is an ANS compliant C64 Forth and very small.