I have my processing code in dev/processing and my Arduino code put itself in Documents/Arduino.
However, whenever I get into one environment, it changes the most recent directory for the other because Arduino is written in processing.
Is there any quick way to disconnect the two environments so that they don't use the same location for "most recent directory?" I don't know whether the mechanism is a file, a registry entry or what, but I'm on Windows 8.1
I am using both Arduino IDE as well as Processing 2.1.2 in Windows 7 environment. It doesn't change the directory.
Since you are using Windows 8.1 (which is recently released), you may face very weird problems as those softwares are not tested on those OS. You will find errors for even other softwares that are designed before Windows 8.
Related
OS: Win 8.1, x86
I am trying to develop an IFilter for a proprietary file format. The IPersistStream interface is implemented in the filter (although there is no tool to test this interface...). The DLL goes through all the tests in the IFilter test suite (ifilttst, filtdump, filtreg; ifilttst emitted property/values are correct), it is installed in c:\windows\system32 but it is not properly run by SearchFilterHost.exe used by Windows indexing services. Nothing is indexed.
I used Process Monitor (procmon.exe) to look at when SearchFilterHost is using the IFilter. During re-indexing of the disk or when a file name handled by the IFilter is changed, SearchFilterHost loads the image of the IFilter, but then nothing else happens.
Dependency Walker found DLLs that were missing (some are found in the c:\windows\system32) (IEHIMS.DLL, API-MS-WIN-CORExxx.DLL etc...) but I doubt (I could be wrong) it would make much of a difference because the ifilttst is running fine.
I am at my wit's end. Could someone help?
Thanks
Does anyone know if Powerbuilder 10 is compatible with Windows 8 (Both the IDE and the runtime module)?
It seems like 11.5 is officially supported, but I couldn't find any info on PB 10's compatibility on Windows 8.
If it isn't, any tips on the migration process from 10->Further version? (Anything particular we have to watch out for?)
You should have no problem with running PB10 applications on Windows 8, appart perhaps not being not fully compliant with Win8 standards (concerning the placement of application data files, access rights on files, and so on mostly related to UAC file virtualization).
Neither you should have big problems with running the IDE, but maybe some minor issues (I think about an issue on the retrieval argument editor on PB11.5 that could also address PB10).
This is one of those things where you just have to try it yourself. The number of PowerBuilder developers with Windows 8 is likely very small.
I am supposed to be getting a Surface Pro 2 when they come out Oct 22nd which will run Windows 8.1. Hopefully there won't be any issues.
I am not sure about PB10 but I have used PB 10.5 in Win8 with no problem.
We have serious issues with running a PB10 application on Windows 8 computers.
Application runs fine until user enters text in datawindow fields, the application "stopped working". The problem is that it happens randomly, 10 fields can be entered without a problem but at the next field the "stopped working" pops up en the application is closed the next time it might happen after entering 2 fields.
The same application runs already for years on many computers unders XP, Vista, Windows 7 without any issue.
Until now we still have no clou what is causing it. Also we have no idea where to start searching.
The application is developed andf deployed under XP.
Next week we are going to setup a development environment under Windows, hopefully this will give us some more light on the issue.
Two things you need to realize:
PB10 was built (and support development stopped) before before Win8 was conceived, so obviously Sybase couldn't do anything in PB to help with Win8 compatibility. You're relying on MS's ability to maintain a backward compatible environment. IME, they do a pretty good job (better than my experience upgrading in the Unix world, but I'd imagine YMMV), but it's never perfect.
PowerBuilder is powerful enough to allow you to build an application that will break under any operating system. PB10 may have been supported on XP, but I guarantee you that I could have written something that violated an XP rule, or corrupted memory, or whatever, and would have been broken under XP. (I've seen memory corruptions that didn't manifest themselves until after an OS upgrade or some other change; so "broken" may not even manifest symptoms yet.) Is that Sybase's fault? I don't think so. They're the rope manufacturer; if you hang yourself....
Bottom line is what's already been said: no matter what the manufacturer or anyone else says, the only answer worth anything is the results of your own testing. My "Hello World" app may run in Win8 just fine, but your app that taps into the TCP/IP stack, leverage protected mode calls, sending printing language codes directly to the point-of-sale bar code printer, etc....
Good luck,
Terry.
I think this is a common problem for all developers using Windows CE 6.0 operating systems on specific hardware. I have a client that needs a custom operating system for its ICOP PDX-089T PC with Touch panel, that is based on DM&P SoC CPU Vortex86DX-1GHz.
I do not have the hardware with me, so every time I make a change I have to send at least the NK.bin file, or the whole ghost image to the client to make the tests for.
Is there any way to build a custom Windows CE emulator to add it to Visual Studio 2005 for testing or may be a custom virtual machine to launch it through VMWare or Virtual PC?
I tried some guidelines from the internet to build one, but every effort in making one resulted in hanging up my PC.
Does anybody have similar needs and some solution?
Note: The emulator I need is for Vortex86DX processor and ICOP board.
Microsoft abandoned the x86 Emulator some time ago, choosing to support only an ARM emulator (the BSP ships in the box with Platform Builder 6.0). This means that you can't create an emulator for the x86 processor, though I'm hard-pressed to think of a scenario where you'd really need to and where just getting hardware isn't a better solution for anyway.
There is a BSP for doing Virtual PC OS builds that would run on x86. It's not had much activity in some time, and I've never tried it, so YMMV.
I have created a c# application in ubuntu using monodevelop. It is running well in ubuntu.
I tried to run that application(firstgtk.exe file created after running in ubuntu)in windows.But it showing error message.How can i make to portable in both linux and windows?
The error message is:
when i click the firstgtk.exe file, a command prompt has come.It is blank. At the same moment microsoft message(send Error report or don't send):
firstgtk has encountered a problem and needs to close.
When i click don't send button, command prompt and message box are gone.
Mono compiles down to CIL code and is completely portable to .NET or Mono on other platforms. I can compile my C# code on a Mac and run the resulting EXE on Linux or Windows under either .NET or Mono.
Without the actual error message we can only guess the issue here. That said, in my experience, the most common reasons an application written in Mono on Linux/UNIX would create an error on Windows are pathnames with platform specific path separators or case sensitivity issues. The Windows file system is not case sensitive but they are on Linux/UNIX.
Another possibility is that you are using Mono on one platform and trying to run it on .NET on the other. Mono ships with a number of libraries that are not present in .NET on Windows.
Actually, I guess a final possibility is that GTK# is a common way to produce GUI code on Mono. GTK# relies on the GTK+ C library being present which is very common on Linux but unlikely on Windows unless it has been explicitly installed.
We really need to know what the error message was.
If you're using Gtk#, your app is portable between Windows and Linux. My guess is that you don't have Gtk# installed correctly (or at all?) on Windows. You can download from here. As of this time the latest version is 2.12.10.
Your code should be portable between Linux and Windows. Alas, the binaries are not. ...
Edit: As commenters have pointed out, Mono does produce and use PE executables, though other issues may limit portability.
Hi!
I have an old plugin (as binary, dll), used by my application. It was build for WM2003. And now it crashes the app, if loaded on Windows Mobile 6.1 (WM5 works fine, WM6 too).
The source code is not available and it's no more supported by developer. So I can't rebuild it for WM6.1.
Is it possible to patch or convert the binary to allow it to work on WM6.1 ? If so, how can I do this ?
Thank you.
Edit: I've found, that the problem is in PE loader, which acts not the same on WM6.1 (comparing with WM6 and earlier).
Does this plug-in use MFC or ATL? Earlier versions of WinMo had a different ATL/MFC version baked in, so MFC or ATL apps written in Studio will not work unless you deploy the newer ATL/MFC libraries along with the app, just as the old apps will not work on new devices unless you deploy the old MFC/ATL libraries.
This problem is rare, but some information can be found.
The common solution is to rebuild a binary in VS2008 (TCPMP new VS2008 builds for WM6.1), but this will not help, if you don't have the source code.
I've found the problem explanation and another solution in cegcc mailing list (arm-wince-cegcc on Windows Mobile 6.1). In Windows Mobile 6.1 Memory Management scheme was changes.
This slot arrangement remained pretty constant from Windows Mobile 2003 to Windows Mobile 6.0. However, with the release of Windows Mobile 6.1, things were changed to reduce the DLL pressure and to help out in the Device Manager process space.
In Windows Mobile 6.1, the stacks for the device manager are no longer allocated in the processes’ slot. Instead, the operating system uses slot 59, at the top of the Large Memory Area, for the device manager thread stacks. ...
And the workaround for this issue is to declare the DLL in registry (to tell the OS not to load it in high memory).
I don't like this workaround, so I try to find some binary patcher. And found it :)
It's not really a patcher, it's UPX - the Ultimate Packer for eXecutables. But it solves the problem perfectly. The DLL, packed with UPX don't crashes the application and runs fine.